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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Дата
Msg-id YRMZ44BjPqvQlgl6@paquier.xyz
обсуждение исходный текст
Ответ на Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Michael Meskes <meskes@postgresql.org>)
Ответы Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Список pgsql-hackers
On Tue, Aug 10, 2021 at 09:31:37AM +0200, Michael Meskes wrote:
>> that it could be a good thing.  declare.pgc seems to rely on that
>> already but the tests are incorrect as I mentioned in [2].  For
>> DESCRIBE, that provides data about a result set, I find the
>> assignment
>> of a connection a bit strange, and even if this would allow the use
>> of
>> the same statement name for multiple connections, it seems to me that
>> there is a risk of breaking existing applications.  There should not
>> be that many, so perhaps that's fine anyway.
>
> I don't think we'd break anything given that DECLARE STATEMENT is new.

Sure, DECLARE does not matter as it is new.  However, please note that
the specific point I was trying to make with my link [2] from upthread
is related to the use of cached connection names with DEALLOCATE, as
of this line in the new test declare.pgc:
    EXEC SQL DEALLOCATE PREPARE stmt_2;

And DEALLOCATE is far from being new.

> Also please keep in mind that you can use EXEC SQL AT ... DESCRIBE ...;
> already anyway. Again, not very meaningful but why should we accept a
> connection one way but not the other?

No objections to that.
--
Michael

Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Quirk of pg_temp schemas ...