Thread: SESSION_USER
create_table.sgml mentions SESSION_USER is not supported. I don't think that is true anymore, is it? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> create_table.sgml mentions SESSION_USER is not supported. I don't think
> that is true anymore, is it?
regression=# select session_user;
getpgusername
---------------
postgres
(1 row)
Looking at the spec, we do seem to be missing SYSTEM_USER out of the
four variants the spec mentions. However, considering that we map
them all to the same thing anyway, I can't get too excited about it.
If something is done about making functions have setuid-like behavior,
we'd want to make sure that the appropriate ones of these functions
change value inside a function.
regards, tom lane
Tom Lane writes: > Looking at the spec, we do seem to be missing SYSTEM_USER out of the > four variants the spec mentions. However, considering that we map > them all to the same thing anyway, I can't get too excited about it. SYSTEM_USER is the operating system user that connected to the database system. This is obviously not generally applicable in the environment PostgreSQL runs in, nor is there a universal and reliable way to get this information, so I suggest we don't bother about it. Mapping it to [CURRENT_]USER would certainly be wrong. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Tom Lane writes: > > > Looking at the spec, we do seem to be missing SYSTEM_USER out of the > > four variants the spec mentions. However, considering that we map > > them all to the same thing anyway, I can't get too excited about it. > > SYSTEM_USER is the operating system user that connected to the database > system. This is obviously not generally applicable in the environment > PostgreSQL runs in, nor is there a universal and reliable way to get this > information, so I suggest we don't bother about it. Mapping it to > [CURRENT_]USER would certainly be wrong. > Well, we do already map it. I just documented it. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> SYSTEM_USER is the operating system user that connected to the database
>> system. This is obviously not generally applicable in the environment
>> PostgreSQL runs in, nor is there a universal and reliable way to get this
>> information, so I suggest we don't bother about it. Mapping it to
>> [CURRENT_]USER would certainly be wrong.
> Well, we do already map it. I just documented it.
No we don't!
regression=# select system_user;
ERROR: Attribute 'system_user' not found
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> SYSTEM_USER is the operating system user that connected to the database > >> system. This is obviously not generally applicable in the environment > >> PostgreSQL runs in, nor is there a universal and reliable way to get this > >> information, so I suggest we don't bother about it. Mapping it to > >> [CURRENT_]USER would certainly be wrong. > > > Well, we do already map it. I just documented it. > > No we don't! > > regression=# select system_user; > ERROR: Attribute 'system_user' not found Updated. Thanks. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026