Обсуждение: pgsql/ oc/src/sgml/ref/set_session_auth.sgml r ...
CVSROOT: /cvsroot
Module name: pgsql
Changes by: tgl@postgresql.org 02/05/06 15:47:30
Modified files:
doc/src/sgml/ref: set_session_auth.sgml
src/backend/commands: variable.c
src/backend/parser: gram.y
src/backend/utils/init: miscinit.c
Log message:
Accept SET SESSION AUTHORIZATION DEFAULT and RESET SESSION AUTHORIZATION
to reset session userid to the originally-authenticated name. Also,
relax SET SESSION AUTHORIZATION to allow specifying one's own username
even if one is not superuser, so as to avoid unnecessary error messages
when loading a pg_dump file that uses this command. Per discussion from
several months ago.
Tom Lane writes: > Accept SET SESSION AUTHORIZATION DEFAULT and RESET SESSION AUTHORIZATION > to reset session userid to the originally-authenticated name. Also, > relax SET SESSION AUTHORIZATION to allow specifying one's own username > even if one is not superuser, so as to avoid unnecessary error messages > when loading a pg_dump file that uses this command. Per discussion from > several months ago. I noticed you added SHOW SESSION AUTHORIZATION here as showing the SESSION_USER. I don't think this makes sense, because SET SESSION AUTHORIZATION is not the same as setting the session user only. Also, in response to your comment, no, I don't think RESET all should reset the session user. I think it would be better to treat SET SESSION AUTHORIZATION separately from the other SET commands, since it behaves differently in effect and privileges. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I noticed you added SHOW SESSION AUTHORIZATION here as showing the
> SESSION_USER. I don't think this makes sense, because SET SESSION
> AUTHORIZATION is not the same as setting the session user only.
Well, I added the SHOW mainly so that I could test the thing more
easily, so I'm not wedded to it --- but why not? Why shouldn't
SHOW SESSION AUTHORIZATION show what you last SET? Not sure about
the distinction you are trying to draw.
> Also, in response to your comment, no, I don't think RESET all should
> reset the session user.
Fine, I didn't think so either ... though this might keep us from
folding it into the GUC variables, which was my next project in
that area...
regards, tom lane