Re: proposal: psql: show current user in prompt

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kirk Wolak <wolakk(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: proposal: psql: show current user in prompt
Date: 2023-04-05 15:47:46
Message-ID: CA+TgmoaPGWW5HGvBF0C0oNpo7FuDxVJTP06PtTWoHQSeV+U-Zg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> If the GUC_REPORT should not be used, then only one possibility is enhancing the protocol, about the possibility to read some predefined server's features from the client.
> It can be much cheaper than SQL query, and it can be used when the current transaction is aborted. I can imagine a possibility to read server time or a server session role from a prompt processing routine.
>
> But for this specific case, you need to cache the role name somewhere. You can simply get oid everytime, but for role name you need to access to system catalogue, and it is not possible in aborted transactions. So at the end, you probably should read "role" GUC.
>
> Can this design be acceptable?

I don't think we want to add a dedicated protocol message that says
"send me the role GUC right now". I mean, we could, but being able to
tell the GUC mechanism "please send me the role GUC after every
command" sounds a lot easier to use.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-04-05 15:54:46 Re: Should vacuum process config file reload more often
Previous Message Greg Stark 2023-04-05 15:34:07 Re: Why enable_hashjoin Completely disables HashJoin