Re: Schema variables - new implementation for Postgres 15
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Pavel Stehule <pavel.stehule@gmail.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-13T12:54:21Z
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 →
-
Allow underscores in integer and numeric constants.
- faff8f8e47f1 16.0 cited
-
Remove special outfuncs/readfuncs handling of RangeVar.catalogname.
- 3cece34be842 16.0 cited
-
Remove extra space from dumped ALTER DEFAULT PRIVILEGES.
- 2af33369e794 16.0 cited
-
Create FKs properly when attaching table as partition
- b0284bfb1db5 16.0 cited
-
psql: improve tab-complete's handling of variant SQL names.
- 02b8048ba5dc 15.0 cited
On Wed, 3 Nov 2021 at 13:05, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > 2) I find this a bit confusing: > > SELECT non_existent_variable; > test=# select s; > ERROR: column "non_existent_variable" does not exist > LINE 1: select non_existent_variable; > > I wonder if this means using SELECT to read variables is a bad idea, and > we should have a separate command, just like we have LET (instead of > just using UPDATE in some way). > Hmm. This way of reading variables worries me for a different reason -- I think it makes it all too easy to break existing applications by inadvertently (or deliberately) defining variables that conflict with column names referred to in existing queries. 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. Similarly, there's ambiguity between alias.colname and schema.variablename. So, for example, if I do the following: CREATE SCHEMA n; CREATE VARIABLE n.nspname AS int; then lots of things are broken, including pg_dump and a number of psql meta-commands. I don't think it's acceptable to make it so easy for a user to break the system in this way. Those are examples that a malicious user might use, but even without such examples, I think it would be far too easy to inadvertently break a large application by defining a variable that conflicted with a column name you didn't know about. Regards, Dean