Fwd: Re: proposal: schema variables

Hi

pá 17. 1. 2025 v 15:39 odesílatel Bruce Momjian <bruce(at)momjian(dot)us> napsal:

> On Fri, Jan 17, 2025 at 03:28:55PM +0100, Pavel Stehule wrote:
> > Dne pá 17. 1. 2025 15:16 uživatel Bruce Momjian <bruce(at)momjian(dot)us>
> napsal:
> > Is this really something we are considering applying, since it has
> been
> > around for years? I am unclear on that and we had better know if we
> are
> > going to continue reviewing this.
> >
> > I hope so it is possible, minimally in some basic form. And i think so
> there
> > was real good progres of quality in last three months.
>
> I am not asking if it is improving. I am asking if it is a desired
> feature; see:
>
> https://wiki.postgresql.org/wiki/Todo#Development_Process
> Desirability -> Design -> Implement -> Test -> Review -> Commit
>
> I am asking if we have had the Desirability discussion, and its outcome,
> because if we can't agree on its Desirability, the other stages are
> useless.
>

This discussion was around 2017 when I wrote a proposal and I hadn't a
feeling so we don't write this feature.
Big discussion was related to whether variables should be transactional or
not. Next the patch was stalled from
two reasons: a) there was not necessary infrastructure for utility
commands, b) I searched for ways to ensure
the validity of the content of variables. I found a good solution at the
end of 2022. It is true, so time has changed
from this time, and Postgres and people are different. In this time the
migration from Oracle was stronger
topic.

If you read all the discussion, you can find more times the sentence so
this can be a good feature (not from me).
Surely the session variables can be implemented differently - minimally
there are four different implementations
mssql, db2, mysql and oracle, and there can be unfinished discussion about
which way is better or if the session
variables are necessary. Yes, we can live without it - we are living
without it, but emulation by GUC is not secure,
so some scenarios are not possible, and others are breakneck with
emulation.

I understand the question if we need it is open still and every time. This
feature is interesting for people who
a) use stored procedures
b) use RLS

Both these groups are not the majority of users. But these people are here.

Btw - EDB supports Oracle way, and Postgres Pro uses extension for
emulation. So there is a real request
for this feature. Common solution for Postgres is using GUC. But there is
no possibility to set access
rights so the workaround cannot be secured.

There is one stronger argument for session variables - we are missing
global temporary tables. It is a real
limit and more times I found users with bloated pg_class, pg_attributes due
using temp tables. I don't believe
so we can have a global temp table - it is a significantly more difficult
task than session variables. At the end
session variables are trivial against global temp tables, and can replace
global temp tables in some use cases.
And the solution can be nicer, cleaner, safer than with a workaround based
on GUC.

Regards

Pavel

>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
> EDB https://enterprisedb.com
>
> Do not let urgent matters crowd out time for investment in the future.
>
>
>