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 по дате отправления: