Thread: "is_superuser" parameter creates inconsistencies
Presumably, the "is_superuser" parameter was intended to make the updating of psql's prompt more accurate when SET SESSION AUTHORIZATION is used. However, if the prompt is customized to include the user name (%n), then the prompt changes to reflect the real superuser status, but does not change the user name. I guess we need to pass "session_user" as well. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Presumably, the "is_superuser" parameter was intended to make the updating
> of psql's prompt more accurate when SET SESSION AUTHORIZATION is used.
> However, if the prompt is customized to include the user name (%n), then
> the prompt changes to reflect the real superuser status, but does not
> change the user name. I guess we need to pass "session_user" as well.
Seems reasonable. IIRC the only addition needed to the server code is
to set a flag in the variable's GUC entry.
regards, tom lane
Has this been addressed? --------------------------------------------------------------------------- Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Presumably, the "is_superuser" parameter was intended to make the updating > > of psql's prompt more accurate when SET SESSION AUTHORIZATION is used. > > However, if the prompt is customized to include the user name (%n), then > > the prompt changes to reflect the real superuser status, but does not > > change the user name. I guess we need to pass "session_user" as well. > > Seems reasonable. IIRC the only addition needed to the server code is > to set a flag in the variable's GUC entry. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Presumably, the "is_superuser" parameter was intended to make the updating > > of psql's prompt more accurate when SET SESSION AUTHORIZATION is used. > > However, if the prompt is customized to include the user name (%n), then > > the prompt changes to reflect the real superuser status, but does not > > change the user name. I guess we need to pass "session_user" as well. > > Seems reasonable. IIRC the only addition needed to the server code is > to set a flag in the variable's GUC entry. Is this a TODO item or something we want to address for 7.4? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > Tom Lane wrote: > > Peter Eisentraut <peter_e@gmx.net> writes: > > > Presumably, the "is_superuser" parameter was intended to make the updating > > > of psql's prompt more accurate when SET SESSION AUTHORIZATION is used. > > > However, if the prompt is customized to include the user name (%n), then > > > the prompt changes to reflect the real superuser status, but does not > > > change the user name. I guess we need to pass "session_user" as well. > > > > Seems reasonable. IIRC the only addition needed to the server code is > > to set a flag in the variable's GUC entry. > > Is this a TODO item or something we want to address for 7.4? I'd like to address it for 7.4, but it looks a bit more difficult than it seemed at first, because session_user isn't in GUC at all, so there is no infrastructure to pass it to the client. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> Is this a TODO item or something we want to address for 7.4?
> I'd like to address it for 7.4, but it looks a bit more difficult than it
> seemed at first, because session_user isn't in GUC at all, so there is no
> infrastructure to pass it to the client.
We'd have to add it, presumably as a read-only variable. I didn't think
that was particularly difficult though ...
regards, tom lane
This item has been added to the 7.4 open items list: ftp://momjian.postgresql.org/pub/postgresql/open_items Allow SET SESSION AUTHORIZATION to update the psql %n user display --------------------------------------------------------------------------- Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Bruce Momjian writes: > >> Is this a TODO item or something we want to address for 7.4? > > > I'd like to address it for 7.4, but it looks a bit more difficult than it > > seemed at first, because session_user isn't in GUC at all, so there is no > > infrastructure to pass it to the client. > > We'd have to add it, presumably as a read-only variable. I didn't think > that was particularly difficult though ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > Allow SET SESSION AUTHORIZATION to update the psql %n user display This already works. -- Peter Eisentraut peter_e@gmx.net
OK, item remvoed. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > Allow SET SESSION AUTHORIZATION to update the psql %n user display > > This already works. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073