2013/6/24 Tom Lane <t...@sss.pgh.pa.us> > Albe Laurenz <laurenz.a...@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.) -- // Dmitriy.
