Re: Schema variables - new implementation for Postgres 15

Hi

so 25. 5. 2024 v 3:29 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > we can introduce special safe mode started by
> > set enable_direct_variable_read to off;
> > and allowing access to variables only by usage dedicated function
> > (supported by parser) named like variable or pg_variable
>
> Didn't we learn twenty years ago that GUCs that change query
> semantics are an awful idea? Pick a single access method
> for these things and stick to it.
>

I propose another variants. First we can introduce pseudo function VAR( ).
The argument should be session variables. The name of this function can be
pgvar, globvar, ... We can talk about good name, it should not be too long,
but it is not important now. The VAR() function will be pseudo function
like COALESCE, so we can easily to set correct result type.

I see possible variants

1. for any read of session variable, the VAR function should be used
(everywhere), the write is not problem, there is not risk of collisions.
When VAR() function will be required everywhere, then the name should be
shorter.

SELECT * FROM tab WHERE id = VAR(stehule.myvar);
SELECT VAR(okbob.myvar);

2. the usage of VAR() function should be required, when query has FROM
clause, and then there is in risk of collisions. Without it, then the VAR()
function can be optional (it is modification of Wolfgang or Alvaro
proposals). I prefer this syntax before mentioning in FROM clause, just I
think so it is less confusing, and FROM clause should be used for
relations, and not for variables.

SELECT * FROM tab WHERE id = VAR(okbob.myvar)
SELECT okbob.myvar;

3. Outside PL the VAR() function will be required, inside PL the VAR
function can be optional (and we can throw an exception) when we found
collision like now

What do you think about this proposal? And if you can accept it, what
version?

I think so implementation of any proposed variant should be easy. I can add
extra check to plpgsql_check if the argument of VAR() function is in
possible collision with other identifiers in query, but for proposed
variants it is just in nice to have category

Regards

Pavel

>
> regards, tom lane
>