Re: Schema variables - new implementation for Postgres 15

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Schema variables - new implementation for Postgres 15
Дата
Msg-id CAFj8pRCPPm6o12hawtFLAOq7E830R6xuKB2+CU0maXUMua9mKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Schema variables - new implementation for Postgres 15  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Schema variables - new implementation for Postgres 15
Список pgsql-hackers


so 25. 5. 2024 v 3:29 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> we can introduce special safe mode started by
> set enable_direct_variable_read to off;
> and allowing access to variables only by usage dedicated function
> (supported by parser) named like variable or pg_variable

Didn't we learn twenty years ago that GUCs that change query
semantics are an awful idea?  Pick a single access method
for these things and stick to it.

I don't think the proposed GUC exactly changes query semantics - it is equivalent of plpgsql options: plpgsql_extra_xxxx or #variable_conflict. It allows us to identify broken queries. And for tools that generates queries is not problem to wrap reading variable by special pseudo function. The code where pseudo function will be used should to work with active or inactive strict mode (related to possibility to use variables).

Sure there is more possibilities, but I don't want to lost the possibility to write code like

CREATE TEMP VARIABLE _x;

LET _x = 'hello';

DO $$
BEGIN
  RAISE NOTICE '%', _x;
END;
$$;

So I am searching for a way to do it safely, but still intuitive and user friendly.

Regards

Pavel

 

                        regards, tom lane

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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: Volatile write caches on macOS and Windows, redux
Следующее
От: Bertrand Drouvot
Дата:
Сообщение: relfilenode statistics