On Tue, 8 Aug 2023 at 07:20, Pavel Stehule <pavel.steh...@gmail.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?
