Tom Lane <tgl@xxxxxxxxxxxxx> writes:
> Greg Stark <gsstark@xxxxxxx> writes:
> > It seems the spurious SET SESSION AUTHORIZATION commands appear after any
> > REVOKE/GRANT pair.
>
> Oh, right. In order to handle grants with GRANT OPTION, the dump data
> may need to include SET SESSION AUTHORIZATION commands; so the code
> assumes that it doesn't know the authorization any more after emitting
> an ACL entry. Not a bug. It could possibly be smarter (eg grep the
> text for "SET SESSION AUTHORIZATION" before deciding this)
Wouldn't it make more sense to have a global state variable that held the
current user and anyone invoking SET SESSION AUTHORIZATION has to set that
state variable?
Or have a function responsible for emitting SET SESSION AUTHORIZATION and bar
other functions from doing it manually. Then have a local static variable in
that function responsible for keeping state.
> but since that's not the default mode anymore anyway, I'm not very
> concerned.
What's not the default mode? I'm just running "pg_dump -U postgresql -s db"
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
