Re: Schema variables - new implementation for Postgres 15

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Schema variables - new implementation for Postgres 15
Дата
Msg-id CAFj8pRD9iEpPN=qX1FKtNxYha9B48sZVqAjFgck7Ah0DpFckOg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Schema variables - new implementation for Postgres 15  ("Joel Jacobson" <joel@compiler.org>)
Ответы Re: Schema variables - new implementation for Postgres 15  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


čt 13. 1. 2022 v 18:01 odesílatel Joel Jacobson <joel@compiler.org> napsal:
On Thu, Jan 13, 2022, at 20:12, Pavel Stehule wrote:
>I cannot imagine how the "window" keyword can work in SQL context. In Javascript "window" is an object - it is not a keyword, and it makes sense in usual Javascript context inside HTML browsers.

I was thinking since Javascript is by far the most known programming language, the "window" word would be familiar and easy to remember, but I agree, it's not perfect.

Mainly the "window" is just a global variable. It is not a special keyword. So the syntax object.property is usual.


Hm, "values" would be nice, it's reserved in SQL:2016 [1] and in DB2/Mimer/MySQL/Oracle/SQL Server/Teradata [2], but unfortunately not in PostgreSQL [1], so perhaps not doable.

Syntax:

values.[schema name].[variable name]

This doesn't help too much. This syntax is too long. It can solve the described issue, but only when all three parts will be required, and writing every time VALUES.schemaname.variablename is not too practical. And if we require this three part identifier every time, then it can be used with the already supported dbname.schemaname.varname. Almost all collisions can be fixed by using a three part identifier. But it doesn't look too handy.

I like the idea of prioritizing tables over variables with warnings when collision is detected. It cannot break anything. And it allows to using short identifiers when there is not collision. If somebody don't want to any collision then can use schema "vars", "values", or what he/she likes. It is near to your proposal - it is not too often so people use table alias like "values" (although in EAV case it is possible).



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Efrain J. Berdecia"
Дата:
Сообщение: Re: Custom Operator for citext LIKE predicates question
Следующее
От: Robert Haas
Дата:
Сообщение: Re: SLRUs in the main buffer pool, redux