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: Marcos Pegoraro <marcos@f10.com.br>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Jaime Casanova <jcasanov@systemguards.com.ec>, Erik Rijkers <er@xs4all.nl>, Gilles Darold <gilles@darold.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2022-01-14T11:07:13Z
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.

pá 14. 1. 2022 v 11:49 odesílatel Marcos Pegoraro <marcos@f10.com.br>
napsal:

> For example, if I define a variable called "relkind", then psql's \sv
>> meta-command is broken because the query it performs can't distinguish
>> between the column and the variable.
>>
>> If variables use : as prefix you´ll never have these conflicts.
>
> select relkind from pg_class where relkind = :relkind
>

This syntax is used for client side variables already.

This is similar to MSSQL or MySQL philosophy. But the disadvantage of this
method is the impossibility of modularization - all variables are in one
space (although there are nested scopes).

The different syntax disallows any collision well, it is far to what is
more usual standard in this area. And if we introduce special syntax, then
there is no way back. We cannot use :varname - this syntax is used already,
but we can use, theoretically, @var or $var. But, personally, I don't want
to use it, if there is possibility to do without it. The special syntax can
be used maybe for direct access to function arguments, or for not
persistent (temporal) session variables like MSSQL. There is a relatively
big space of functionality for session variables, and the system that I
used is based on ANSI SQL/PSM or DB2 and it is near to Oracle. It has a lot
of advantages for writing stored procedures. On other hand, for adhoc work
the session variables like MySQL (without declaration) can be handy, so I
don't want to use (and block) syntax that can be used for something
different.




>
>