Re: Schema variables - new implementation for Postgres 15
От | Dean Rasheed |
---|---|
Тема | Re: Schema variables - new implementation for Postgres 15 |
Дата | |
Msg-id | CAEZATCW4PEWNC_tkXx5wzJij9at4ctpWWTr7Sa1bthwPRTm+fg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Schema variables - new implementation for Postgres 15 (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Schema variables - new implementation for Postgres 15
Re: Schema variables - new implementation for Postgres 15 Re: Schema variables - new implementation for Postgres 15 |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: