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: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-23T19:46:31Z
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.

Hi

st 22. 5. 2024 v 16:14 odesílatel Dmitry Dolgov <9erthalion6@gmail.com>
napsal:

> > On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote:
> > On 18.05.24 13:29, Alvaro Herrera wrote:
> > > I want to note that when we discussed this patch series at the dev
> > > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> > > schema variables at all because of the fact that creating a variable
> > > would potentially change the meaning of queries by shadowing table
> > > columns.  But this turns out to be incorrect: it's_variables_  that are
> > > shadowed by table columns, not the other way around.
> >
> > But that's still bad, because seemingly unrelated schema changes can make
> > variables appear and disappear.  For example, if you have
> >
> > SELECT a, b FROM table1
> >
> > and then you drop column b, maybe the above query continues to work
> because
> > there is also a variable b.  Or maybe it now does different things
> because b
> > is of a different type.  This all has the potential to be very confusing.
>
> Yeah, that's a bummer. Interestingly enough, the db2 implementation of
> global session variables mechanism is mentioned as similar to what we
> have in the patch. But weirdly, the db2 documentation just states
> possibility of a resolution conflict for unqualified names, nothing
> else.
>

I found document https://www.ibm.com/docs/it/i/7.3?topic=variables-global

If I understand well, then the same rules are applied for qualified or not
qualified identifiers (when there is a conflict), and the variables have
low priority.

The db2 has the possibility to compile objects, and it can block the usage
variables created after compilation - (if I understand well the described
behaviour).

Regards

Pavel