Re: proposal: possibility to read dumped table's name from file
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Dean Rasheed <dean.a.rasheed@gmail.com>, Stephen Frost <sfrost@snowman.net>,
Surafel Temesgen <surafel3000@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, vignesh C <vignesh21@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-07-12T22:47:05Z
Lists: pgsql-hackers
On 7/13/21 12:08 AM, Daniel Gustafsson wrote: >> On 10 Jul 2021, at 17:47, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > >> So if it was up to me, I'd go back to the original format or something close it. So something like this: >> >> [+-] OBJECT_TYPE_PATTERN OBJECT_NAME_PATTERN > > That still leaves the parsing with quoting and escaping that needs to be done > less trivial and more bespoke than what meets the eye, no? > Yes, it'd require proper escaping/quoting of the fields/identifiers etc. > As mentioned upthread, I'm still hesitant to add a file format which deosn't > have any version information of sorts for distinguishing it from when the > inevitable "now wouldn't it be nice if we could do this too" patch which we all > know will come. The amount of selectivity switches we have for pg_dump is an > indication about just how much control users like, this will no doubt be > subject to the same. > I'm not going to fight against some sort of versioning, but I think keeping the scope as narrow as possible would make it unnecessary. That is, let's stick to the original goal to allow passing filtering rules that would not fit on the command-line, and maybe let's make it a bit more flexible to support other object types etc. IMHO the filtering rules are simple enough to not really need elaborate versioning, and if a more advanced rule is proposed in the future it can be supported in the existing format (extra field, ...). Of course, maybe my imagination is not wild enough. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix array subscript warnings
- 17935e1fdf0a 17.0 landed
-
Read include/exclude commands for dump/restore from file
- a5cf808be55b 17.0 landed
-
Allow records to span multiple lines in pg_hba.conf and pg_ident.conf.
- 8f8154a503c7 14.0 cited