From: | Jelte Fennema <postgres(at)jeltef(dot)nl> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
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-08-10 12:05:44 |
Message-ID: | CAGECzQT9G_hNgW1K7jizF6a3b23szXm+s=cwiRn5tAbSonPTOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 8 Aug 2023 at 07:20, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> The reason why I implemented separate flow is usage from psql and independence of transaction state. It is used for the \set command, that is non-transactional, not SQL. If I inject this message to some other flow, I lose this independence.
I still don't understand the issue that you're trying to solve by
introducing a new flow for handling the response. What do you mean
with independence of the transaction state? That it is not rolled-back
in a case like this?
BEGIN;
\set PROMPT '%N'
ROLLBACK;
That seems more like a Postgres server concern, i.e. don't revert the
change back on ROLLBACK. (I think your current server-side
implementation already does that)
I guess one reason that I don't understand what you mean is that libpq
doesn't really care about "transaction state" at all. It's really a
wrapper around a socket with easy functions to send messages in the
postgres protocol over it. So it cares about the "connection state",
but not really about a "transaction state". (it does track the current
connection state, but it doesn't actually use the value except when
reporting the value when PQtransactionStatus is called by the user of
libpq)
> Without independence on transaction state and SQL, I can just implement some SQL function that sets reporting for any GUC, and it is more simple than extending protocol.
I don't understand why this is not possible. As far as I can tell this
should work fine for the usecase of psql. I still prefer the protocol
message approach though, because that makes it possible for connection
poolers to intercept the message and handle it accordingly. And I see
some use cases for this reporting feature for PgBouncer as well.
However, I think this is probably the key thing that I don't
understand about the problem you're describing: So, could you explain
in some more detail why implementing a SQL function would not work for
psql?
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2023-08-10 12:43:50 | Re: proposal: psql: show current user in prompt |
Previous Message | John Naylor | 2023-08-10 11:37:24 | Re: [PATCH] Add loongarch native checksum implementation. |