Fwd: Re: proposal: schema variables - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Fwd: Re: proposal: schema variables |
| Date | |
| Msg-id | CAFj8pRAki6SGw2Dw-73ubQoDY9yPvfUQBjqr_LN35T7YBcsxmQ@mail.gmail.com Whole thread Raw |
| In response to | Re: Re: proposal: schema variables (jian he <jian.universality@gmail.com>) |
| Responses |
Re: Fwd: Re: proposal: schema variables
|
| List | pgsql-hackers |
Hi
pá 17. 1. 2025 v 15:39 odesílatel Bruce Momjian <bruce@momjian.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@momjian.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@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
pgsql-hackers by date: