Albe Laurenz <laurenz.albe@wien.gv.at> writes: > Why do you need to track prepared statements on the client side?
The proposed change would fail to allow that anyway; consider the possibility of a server-side function doing one or more PREPAREs or DEALLOCATEs. The command tag would be completely inadequate for reporting that.
Ah, indeed! I does not considered that. Thanks for the info.
Space is also a problem, since existing clients expect the tags to be pretty short --- for instance, libpq has always had a hard-wired limit of 64 bytes (CMDSTATUS_LEN) on what it can store for the tag. That's not enough for a command name plus a full-length identifier.
:-(
If we were to try to do this, we'd need to invent some other reporting mechanism, perhaps similar to ParameterStatus for GUC_REPORT variables. But that would be a protocol break, which means it's unlikely to happen anytime soon.
Is there are chance to add this idea in the TODO?
Btw, maybe we'd need also to identify each prepared statement (and portal) not only
by the name, but by the automatically generated id included by the backend in
ParseComplete and then pass this id with Bind messages to let the backend throws
an error if the prepared statement (portal) is deallocated? (This would be truly
automatically prepared statement backend tracking as menioned by Albe.)
