Horton
Menu

Re: pg_dump needs SELECT privileges on irrelevant extension table

Jacob Champion <champion.p@gmail.com>

View thread
From: Jacob Champion <champion.p@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Andrew Dunstan <andrew@dunslane.net>, Akshat Jaimini <destrex271@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Aleksander Alekseev <aleksander@timescale.com>
Date: 2023-10-23T18:21:30Z
Lists: pgsql-bugs, pgsql-hackers 
On Wed, Oct 18, 2023 at 1:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > 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?
>
> Yes.  But I'd say that's unsupported, just like making other ad-hoc
> changes to extension objects is unsupported (and the effects will be
> lost on dump/reload).  We specifically have support for user-added
> ACLs, and that's good, but don't claim that we have support for
> doing the same with policies.

Is this approach backportable?

(Adding Aleks to CC -- Timescale may want to double-check that the new
proposal still works for them.)

Thanks,
--Jacob

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't try to dump RLS policies or security labels for extension objects.