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).  (Dmitriy Igrishin <dmitigr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dmitriy Igrishin
Дата:
Сообщение: Re: [HACKERS] Frontend/backend protocol improvements proposal (request).
Следующее
От: Ziggy Skalski
Дата:
Сообщение: Re: .pgpass being ignored