Subject: Re: Schema variables - new implementation for Postgres 15

From: [email-masked]
Date: Wed, 22 May 2024 20:21:08 +0200

Alvaro Herrera:
> Perhaps the solution to all this is to avoid having the variables be
> implicitly present in the range table of all queries.  Instead, if you
> need a variable's value, then you need to add the variable to the FROM
> clause;

+1

This should make it easier to work with composite type schema variables 
in some cases.  It could also enable schema qualifying of schema 
variables, or at least make it easier to do, I think.

In this case variables would share the same namespace as tables and 
views, right?  So I could not create a variable with the same name as 
another table.  Which is a good thing, I guess.  Not sure how it's 
currently implemented in the patch.

Best,

Wolfgang

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 22 May 2024 21:09:54 +0200

> currently implemented in the patch.

I don't like this. Sure, this fixes the problem with collisions, but then
we cannot talk about variables. When some is used like a table, then it
should be a table. I can imagine memory tables, but it is a different type
of object. Table is relation, variable is just value. Variables should not
have columns, so using the same patterns for tables and variables has no
sense. Using the same catalog for variables and tables. Variables just hold
a value, and then you can use it inside a query without necessity to write
JOIN. Variables are not tables, and then it is not too confusing so they
are not transactional and don't support more rows, more columns.

The problem with collision can be solved very easily - just use a dedicated
schema (only for variables) and don't use it in the search path.

In this case, the unwanted collision is not too probable - although it is
possible, if you use a schema name for a variable same like table name or
alias name.

I can use

CREATE SCHEMA __;
CREATE VARIABLE __.a AS int;

SELECT __.a;

although it is maybe wild, probably nobody will use alias or table name __
and then there should not be any problem