út 4. 4. 2023 v 19:55 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes: > út 4. 4. 2023 v 18:42 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal: >> Basically, I want to reject this on the grounds that it's not >> useful enough to justify the overhead of marking the "role" GUC >> as GUC_REPORT. The problems with it not going to work properly >> with old servers are an additional reason not to like it.
> If I understand to next comment correctly, the overhead should not be too > big
Yeah, but how big is the use-case? The reason I'm skeptical is that half the time what you're going to get is "none":
$ psql psql (16devel) Type "help" for help.
regression=# show role; role ------ none (1 row)
That's required by SQL spec I believe, but that doesn't make it useful data to keep in one's prompt.
Who needs it, and who uses different roles, then very quickly uses SET ROLE TO command.
But I fully agree so current behavior can be a little bit messy. I like this feature, and I think it can have some benefits. Proposed implementation is minimalistic.
One hard problem is translation of the oid of current_user to name. It requires an opened transaction, and then it cannot be postponed to the end of the statement. On the other hand, when the change of role is done inside a nested command, then it should not be visible from the client side.
Can you accept the introduction of a new invisible GUC, that can be modified only by SET ROLE TO command when it is executed as top command?
It was stupid idea.
There can be implemented fallbacks. When the role is "none", then the :USER can be displayed instead.
It can work, because the custom role "none" is not allowed
(2023-04-04 21:10:25) postgres=# create role none; ERROR: role name "none" is reserved LINE 1: create role none;