pg_restore -N loses extension comment
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: pgsql-hackers@lists.postgresql.org
Date: 2024-05-07T12:28:58Z
Lists: pgsql-hackers
pg_dump -Fc |pg_restore -l -N schema: | 2; 3079 18187 EXTENSION - pg_buffercache Without -N schema also shows: | 2562; 0 0 COMMENT - EXTENSION pg_buffercache I mean literal s-c-h-e-m-a, but I suppose anything else will work the same. BTW, I noticed that pg_restore -v shows that duplicate dependencies can be stored. We see things like this (and worse). | 4284; 1259 191439414 VIEW public wmg_server_view telsasoft | ; depends on: 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 23087 612 I see that's possible not only for views, but also tables. That's probaably wasteful of CPU, at least. -- Justin
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
- a3c00ab15450 12.20 landed
- b99dc6694ca6 13.16 landed
- 52b23b4e1c6f 14.13 landed
- 6a458d93ba5f 15.8 landed
- 5dce8ce0ac48 16.4 landed
- c1aea206e3e3 17.0 landed