Re: proposal: possibility to read dumped table's name from file
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, Daniel Gustafsson <daniel@yesql.se>, Dean Rasheed <dean.a.rasheed@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Surafel Temesgen <surafel3000@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, vignesh C <vignesh21@gmail.com>
Date: 2021-07-13T23:00:38Z
Lists: pgsql-hackers
On 2021-Jul-13, Stephen Frost wrote: > The simplest possible format isn't going to work with all the different > pg_dump options and it still isn't going to be 'simple' since it needs > to work with the flexibility that we have in what we support for object > names, That's fine. If people want a mechanism that allows changing the other pg_dump options that are not related to object filtering, they can implement a configuration file for that. > and is still going to require people write a new parser and > generator for it instead of using something existing. Sure. That's not part of this patch. > I don't know that the options that I suggested previously would > definitely work or not but they at least would allow other projects like > pgAdmin to leverage existing code for parsing and generating these > config files. Keep in mind that this patch is not intended to help pgAdmin specifically. It would be great if pgAdmin uses the functionality implemented here, but if they decide not to, that's not terrible. They have survived decades without a pg_dump configuration file; they still can. There are several votes in this thread for pg_dump to gain functionality to filter objects based on a simple specification -- particularly one that can be written using shell pipelines. This patch gives it. > I'm not completely against inventing something new, but I'd really > prefer that we at least try to make something existing work first > before inventing something new that everyone is going to have to deal > with. That was discussed upthread and led nowhere. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Nunca se desea ardientemente lo que solo se desea por razón" (F. Alexandre)
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