Re: proposal: psql: show current user in prompt

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jelte Fennema <postgres(at)jeltef(dot)nl>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-07-24 19:15:43
Message-ID: CAFj8pRBDyjwk1-xhnAJQ4cC+G0tMq2ZozL7Pocun56U9MbvEhw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

po 8. 5. 2023 v 14:22 odesílatel Jelte Fennema <postgres(at)jeltef(dot)nl> napsal:

> I'm very much in favor of adding a way to support reporting other GUC
> variables than the current hardcoded list. This can be quite useful to
> support some amount of session state in connection poolers.
>
> Some general feedback on the patch:
> 1. I don't think the synchronization mechanism that you added should
> be part of PQlinkParameterStatus. It seems likely for people to want
> to turn on reporting for multiple GUCs in one go. Having to
> synchronize for each would introduce unnecessary round trips. Maybe
> you also don't care about syncing at all at this point in time.
>

I don't understand how it can be possible to do it without. I need to
process possible errors, and then I need to read and synchronize protocol.
I didn't inject
this feature to some oher flow, so I need to implement a complete process.
For example, PQsetClientEncoding does a PQexec call, which is much more
expensive. Unfortunately, for this feature, I cannot change some local
state variables, but I need to change the state of the server. Own message
is necessary, because we don't want to be limited by the current
transaction state, and then we cannot reuse PQexec.

The API can be changed from PQlinkParameterStatus(PGconn *conn, const char
*paramName)

to

PQlinkParameterStatus(PGconn *conn, int nParamNames, const char *paramNames)

What do you think?

Regards

Pavel

>
> 2. Support for this message should probably require a protocol
> extension. There is another recent thread that discusses about adding
> message types and protocol extensions:
>
> https://www.postgresql.org/message-id/flat/CA%2BTgmoaxfJ3whOqnxTjT-%2BHDgZYbEho7dVHHsuEU2sgRw17OEQ%40mail.gmail.com#acd99fde0c037cc6cb35d565329b6e00
>
> 3. Some tests for this new libpq API should be added in
> src/test/modules/libpq_pipeline
>
> 4. s/massages/messages
>
>
> Finally, I think this patch should be split into two commits:
> 1. adding custom GUC_REPORT protocol support+libpq API
> 2. using this libpq API in psql for the user prompt
>
> If you have multiple commits (which are rebased on master), you can
> very easily create multiple patch files using this command:
> git format-patch master --base=master --reroll-count={version_number_here}
>
>
> On Fri, 28 Apr 2023 at 07:00, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> >
> >
> > čt 27. 4. 2023 v 7:39 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> napsal:
> >>
> >> Hi
> >>
> >> rebased version + fix warning possibly uninitialized variable
> >
> >
> > fix not unique function id
> >
> > Regards
> >
> > Pavel
> >
> >>
> >> Regards
> >>
> >> Pavel
> >>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-07-24 19:22:50 Re: cataloguing NOT NULL constraints
Previous Message Dean Rasheed 2023-07-24 19:05:39 Re: cataloguing NOT NULL constraints