Peter Eisentraut <pete...@gmx.net> writes:
> 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.
Hm ... I wonder whether those are well-thought-out either.
> 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.
But now that you mention it, isn't that completely broken? What pg_dump
actually prints given this made-up data is
REVOKE ALL ON TYPE myshell FROM PUBLIC;
REVOKE ALL ON TYPE myshell FROM postgres;
GRANT ALL ON TYPE myshell TO PUBLIC;
which seems like a completely insane interpretation. There is no way
that dumping a type from a pre-typacl database and restoring it into
a newer one should end up with the type's owner having no privileges
on it. I'm astonished that we've not gotten bug reports about that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
