Re: proposal: psql: show current user in prompt

po 31. 7. 2023 v 17:46 odesílatel Jelte Fennema <postgres(at)jeltef(dot)nl> napsal:

> On Mon, 24 Jul 2023 at 21:16, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > 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.
>
> I think I might be missing the reason for this then. Could you explain
> a bit more why you didn't inject the feature into another flow?
> Because it seems like it would be better to inserting the logic for
> handling the new response packet in pqParseInput3(), and then wait on
> the result with PQexecFinish(). This would allow sending these
> messages in a pipelined mode.
>
> > For example, PQsetClientEncoding does a PQexec call, which is much more
> expensive.
>
> Yeah, but you'd usually only call that once for the life of the
> connection. But honestly it would still be good if there was a
> pipelined version of that function.
>
> > 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.
>
> I guess this is your reasoning for why it needs its own state machine,
> but I don't think I understand the problem. Could you expand a bit
> more on what you mean? Note that different message types use
> PQexecFinish to wait for their result, e.g. PQdescribePrepared and
> PQclosePrepared use PQexecFinish too and those wait for a
> RowDescription and a Close message respectively. I added the logic for
> PQclosePerpared recently, that patch might be some helpful example
> code:
> https://github.com/postgres/postgres/commit/28b5726561841556dc3e00ffe26b01a8107ee654

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. Proposed message can be injected to other flows
too, I think, but for the proposed psql feature it is not practical.
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.

Regards

Pavel

>
> > The API can be changed from PQlinkParameterStatus(PGconn *conn, const
> char *paramName)
> >
> > to
> >
> > PQlinkParameterStatus(PGconn *conn, int nParamNames, const char
> *paramNames)
>
> That would definitely address the issue with the many round trips
> being needed. But it would still leave the issue of introducing a
> second state machine in the libpq code. So if it's possible to combine
> this new code into the existing state machine, then that seems a lot
> better.
>