Re: proposal: psql: show current user in prompt

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(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 16:40:30
Message-ID: CAFj8pRCqU7PPz2XZAjwuFVvbD7dpTMQnG=Pad2COHGwNdK0w=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

st 5. 4. 2023 v 17:47 odesílatel Robert Haas <robertmhaas(at)gmail(dot)com> napsal:

> 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.
>

I'll try it

Regards

Pavel

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-04-05 17:05:34 Re: Why enable_hashjoin Completely disables HashJoin
Previous Message Stephen Frost 2023-04-05 16:10:00 Re: Disable rdns for Kerberos tests