Re: pg_dump needs SELECT privileges on irrelevant extension table
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <champion.p@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Akshat Jaimini <destrex271@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-18T20:11:59Z
Lists: pgsql-bugs, pgsql-hackers
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > I wrote: > > Why are we marking extension member objects as being subject to SECLABEL > > or POLICY dumping? As the comment notes, that isn't really sensible > > unless what we are dumping is a delta from the extension's initial > > assignments. But we have no infrastructure for that, and none seems > > likely to appear in the near future. > > Here's a quick patch that does it that way. The test changes > are identical to Jacob's v3-0001. What the comment is talking about is that we don't support initial policies, not that we don't support policies on extension tables at all. That said ... even the claim that we don't support such policies isn't supported by code and there are people out there doing it, which creates its own set of problems (ones we should really try to find solutions to though..). This change would mean that policies added by a user after the extension is created would just be lost by a pg_dump/reload, doesn't it? Thanks, Stephen
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't try to dump RLS policies or security labels for extension objects.
- a70f2a57f233 17.0 landed
- 64d2467fc8d3 16.2 landed
- f15147df625f 15.6 landed
- 9e08789d4832 13.14 landed
- 891afa84c27e 12.18 landed
- 15439205d8ce 14.11 landed