Re: [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

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.

In response to

Responses

Browse pgsql-committers by date

  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)

Browse pgsql-hackers by date

  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