Re: OWNER TO on all objects - Mailing list pgsql-hackers

From Tom Lane
Subject Re: OWNER TO on all objects
Date
Msg-id 16138.1087355344@sss.pgh.pa.us
Whole thread Raw
In response to Re: OWNER TO on all objects  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: OWNER TO on all objects
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL 
> compliant, whereas ALTER OWNER is not.  So I'm in favor of changing 
> nothing.

That's a fair point, but you have to admit that it's a bit abstract
while Chris has a real problem he needs to solve.  Our dumps are awfully
low on the SQL-compliance scale anyway :-(

> The examples you listed in you original mail, where the 
> privilege to do something was later dropped so the original state is 
> not reproducible, are to me examples that the privilege system is 
> flawed.

Sure, but we're not fixing the privilege system this time round (unless
you have work in progress you haven't mentioned ;-)).  In any case this
answer is no help for dumping existing databases with "illegal"
configurations, and newer pg_dumps will still be expected to cope with
those.

> You could use ALTER OWNER in those cases only, because those 
> states are not SQL compliant anyway.

Is it really possible for pg_dump to detect such cases and decide which
method to use?  I'd be in favor of this if it were practical to do,
but it sounds suspiciously close to AI-complete ... especially when
considering scenarios involving pg_restore into an existing database ...

This brings up a question for Chris, which is whether he's implemented
this in a way that forces the decision at pg_dump time, or whether
it is made during pg_restore.  I would definitely agree that we need
to postpone the choice of which to do till pg_restore.  In other words,
a dump archive should only show object ownerships and not prejudge
how those ownerships will get set during the restore session.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Improving postgresql.conf
Next
From: Tom Lane
Date:
Subject: Re: Improving postgresql.conf