po 31. 7. 2023 v 17:46 odesÃlatel Jelte Fennema <postg...@jeltef.nl> napsal:
> On Mon, 24 Jul 2023 at 21:16, Pavel Stehule <pavel.steh...@gmail.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. >
