Re: Re: [HACKERS] Frontend/backend protocol improvements proposal (request).
От | Tom Lane |
---|---|
Тема | Re: Re: [HACKERS] Frontend/backend protocol improvements proposal (request). |
Дата | |
Msg-id | 13031.1372082904@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Frontend/backend protocol improvements proposal (request). (Albe Laurenz <laurenz.albe@wien.gv.at>) |
Ответы |
Re: Re: [HACKERS] Frontend/backend protocol improvements
proposal (request).
|
Список | pgsql-general |
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. 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. regards, tom lane
В списке pgsql-general по дате отправления: