Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Дата
Msg-id YOQOf+1EgOTpudkW@paquier.xyz
обсуждение исходный текст
Ответ на Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Michael Paquier <michael@paquier.xyz>)
Ответы RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Список pgsql-hackers
On Tue, Jul 06, 2021 at 04:58:03PM +0900, Michael Paquier wrote:
> I have been chewing on this comment and it took me some time to
> understand what you meant here.  It is true that the ecpglib part, aka
> all the routines you are quoting above, don't rely at all on the
> connection names.  However, the preprocessor warnings generated by
> drop_descriptor() and lookup_descriptor() seem useful to me to get
> informed when doing incorrect descriptor manipulations, say on
> descriptors that refer to incorrect object names.  So I would argue
> for keeping these.

By the way, as DECLARE is new as of v14, I think that the interactions
between DECLARE and the past queries qualify as an open item.  I am
adding Michael Meskes in CC.  I got to wonder how much of a
compatibility break it would be for DEALLOCATE and DESCRIBE to handle
EXEC SQL AT in a way more consistent than DECLARE, even if these are
bounded to a result set, and not a connection.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Can a child process detect postmaster death when in pg_usleep?