From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Fix pg_dump to dump shell types. |
Date: | 2015-08-10 20:00:40 |
Message-ID: | 55C902E8.2010400@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 8/9/15 6:23 PM, Tom Lane wrote:
> It looks to me like the reason for this is that pg_dump forces the
> "typacl" of a type to be '{=U}' when reading the schema data for a
> pre-9.2 type, rather than reading it as NULL (ie default permissions)
> which would result in not printing any grant/revoke commands for
> the object.
>
> I do not see a good reason for that; quite aside from this problem,
> it means there is one more place that knows the default permissions
> for a type than there needs to be. Peter, what was the rationale?
This was probably just copied from how proacl and lanacl are handled,
which predate typacl by quite a bit. Maybe there was a reason in those
days.
It might also have something to do with how owner privileges are
handled. An explicit '{=U}' doesn't create owner privileges, unlike a
null value in that field. Maybe this is necessary if you dump and
restore between databases with different user names.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-08-10 20:40:31 | Re: [COMMITTERS] pgsql: Fix pg_dump to dump shell types. |
Previous Message | Andres Freund | 2015-08-10 15:33:05 | Re: Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization) |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-08-10 20:03:50 | Re: Asynchronous execution on FDW |
Previous Message | Stephen Frost | 2015-08-10 19:40:59 | Re: WIP: SCRAM authentication |