Re: proposal: possibility to read dumped table's name from file
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Erik Rijkers <er@xs4all.nl>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>,
Justin Pryzby <pryzby@telsasoft.com>,
Dean Rasheed <dean.a.rasheed@gmail.com>,
Stephen Frost <sfrost@snowman.net>,
Surafel Temesgen <surafel3000@gmail.com>,
vignesh C <vignesh21@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-10-04T12:54:27Z
Lists: pgsql-hackers
> On 2 Oct 2021, at 08:18, Erik Rijkers <er@xs4all.nl> wrote:
> So the issue is not as serious as it seemed.
This is also not related to this patch in any way, or am I missing a point
here? This can just as well be achieved without this patch.
> The complaint remaining is only that this could somehow be documented better.
The pg_dump documentation today have a large highlighted note about this:
"When --include-foreign-data is specified, pg_dump does not check that the
foreign table is writable. Therefore, there is no guarantee that the
results of a foreign table dump can be successfully restored."
This was extensively discussed [0] when this went in, is there additional
documentation you'd like to see for this?
--
Daniel Gustafsson https://vmware.com/
[0] https://postgr.es/m/LEJPR01MB0185483C0079D2F651B16231E7FC0@LEJPR01MB0185.DEUPRD01.PROD.OUTLOOK.DE
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