Horton

Re: Schema variables - new implementation for Postgres 15

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dmitry Dolgov <9erthalion6@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Sergey Shinderuk <s.shinderuk@postgrespro.ru>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Julien Rouhaud <rjuju123@gmail.com>, dean.a.rasheed@gmail.com, er@xs4all.nl, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2024-05-25T05:10:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow underscores in integer and numeric constants.

  2. Remove special outfuncs/readfuncs handling of RangeVar.catalogname.

  3. Remove extra space from dumped ALTER DEFAULT PRIVILEGES.

  4. Create FKs properly when attaching table as partition

  5. psql: improve tab-complete's handling of variant SQL names.

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
>