Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 21 May 2025 09:21:42 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Marcos Pegoraro <marcos@f10.com.br>,
	jian he <jian.universality@gmail.com>,
	Dmitry Dolgov <9erthalion6@gmail.com>,
	Laurenz Albe <laurenz.albe@cybertec.at>,
	Erik Rijkers <er@xs4all.nl>, Amit Kapila <amit.kapila16@gmail.com>,
	DUVAL REMI <REMI.DUVAL@cheops.fr>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Re: proposal: schema variables
Message-ID: <aC0clv2F-HR1vVvP@paquier.xyz>
References: 
 <CAFj8pRC_2tHski1K4hUMZm0+T4y7na4d8hwgMMF7Y0MXhfUhbg@mail.gmail.com>
 <CAB-JLwaOdMQN838Fy2r2qZLTExfJp0zcjQjmOFVRXhW_-uDNVw@mail.gmail.com>
 <CAFj8pRArtw+Qqzk+Zf2NxjgO=paCBdc54eEma+MsVwtx3j7Atg@mail.gmail.com>
 <CAFj8pRAK_8ym1J=SAdin-vtL0PAachXgjWgU3QrhzinRdBX2sw@mail.gmail.com>
 <CAFj8pRAx-Gb9Ux825cxGNm38qQUOrij1GY6erPRaQ=cpqfiX7g@mail.gmail.com>
 <CAFj8pRCEjG005L=1vGbir-odYdcYxByOAeFVJ_K9eRcRF=MbNQ@mail.gmail.com>
 <aCyYHXhAjXOUPvLO@momjian.us>
 <CAB-JLwY2-Hm_SYbj2td_VKuU8awCwgDr-sOtjHRE2C-Sgg_pFg@mail.gmail.com>
 <aCywNzDx2J3jrY1-@momjian.us>
 <CAFj8pRABfnPMJCzqLKp11q-FhpdteTcAG8Bqm6SOoe-RA2uxcA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="foiHgcmvQry6kJhL"
Content-Disposition: inline
In-Reply-To: 
 <CAFj8pRABfnPMJCzqLKp11q-FhpdteTcAG8Bqm6SOoe-RA2uxcA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aC0clv2F-HR1vVvP%40paquier.xyz>
Precedence: bulk


--foiHgcmvQry6kJhL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> This topic is difficult, because there is no common solution. SQL/PSM is
> almost dead. T-SQL (and MySQL) design is weak and cannot be used for
> security.
> Oracle's design is joined with just one environment. And although almost
> all widely used databases have supported session variables for decades, no
> one design
> is perfect. Proposed design is not perfect too (it introduces possible
> ambiguity) , but I think it can support most wanted use cases (can be
> enhanced in future),
> and it is consistent with Postgres. There are more ways to reduce risk of
> unwanted ambiguity to zero. But it increases the size of the patch.

One thing that I keep hearing about this feature is that this would be
really helpful for migration from Oracle to PostgreSQL, helping a lot
with rewrites of pl/pgsql functions.

There is one page on the wiki about private variables, dating back to
2016:
https://wiki.postgresql.org/wiki/CREATE_PRIVATE_VARIABLE

Perhaps it would help to summarize a bit the pros and cons of existing
implementations to drive which implementation would be the most suited
on a wiki page?  The way standards are defined is by overwriting
existing standards, and we don't have one in the SQL specification.
It's hard to say if there will be one at some point, but if the main
SQL products around the world have one, it pretty much is a point in
favor of having a standard.

Another possible angle that could be taken is to invest in a proposal
for the SQL committee to consider, forcing an actual standard that
PostgreSQL could rely on rather than having one behavior implemented
to have it standard-incompatible a few years after.  And luckily, we
have Vik Fearing and Peter Eisentraut in this community who invest
time and resources in this area.

FWIW, I do agree with the opinion that if you want to propose rebased
versions of this patch set on a periodic basis, you are free to do so.
This is the core concept of an open community.  In terms of my
committer time, I'm pretty much already booked in terms of features
planned for the next release, so I guess that I won't be able to
invest time on this thread.  Just saying.

I know that this patch set has been discussed at FOSDEM at some point,
so others may be able to comment more about that.  That's just one
opinion among many others.
--
Michael

--foiHgcmvQry6kJhL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmgtHJYACgkQnvQgOdby
QH3joxAAjV49Gw/dBn9DQalssKKMNj4kZiqAkL3LACRoCRQoFk+zRASzrPTvp/vB
GZUD4tYQSrD6rJSRNjA8YBfZ91IZ2X95wwN1KJdM21MCv12CAXTAoL6CNYE1+G1G
ABASnTCcqarwh8WRjECOpJMERxIGi2gpF6gz0O1l23sMT7if58+5G9lfj0toc9eB
DUvwVQ5r9IgpUngzcGa0MqTCGgA6dIXTnDWScKH88gyKBoWoEJWd9sWIheFuwALE
DshnG/2f4drxS0WxeaDr6VZ5cRMRB+xeKGIP1ge4Vzg1dx3tJIsoS0BGoZ8vFoR5
SlSzVsn3AYykueNGSsgjoES2zjnHGnh/rBtxeElBdcVF1B0i/zpJeI+IyqMB4AbH
JS8JR8XswGsc6gE+YnH0+3Iy7SAZjxo9H4BwQrch8ewjvhqQAV8z7KtsfKUWs10h
Y09nRf3YHrSLY/1DHbdL+57uciG0IFZkIPydDE7A7tifsNzwJ6av+IdBDjtS+DFW
7bw1rt3hxhac9wmB0LNVZhngPMcYmiX72ETDLPbXCRjM6J8ggt1krsQHrlUOdJiX
HTNVMNa9Kq1YTdqErsQKIhUyEow+b0zyhxs073wqjTuDpwe1mUbSSHwUK4kt+KaF
Bm7dmgvu4pgUhrUFzg7KaJ/LWPnU2ikXAny7Fu3IAHXE9djImhc=
=o2UX
-----END PGP SIGNATURE-----

--foiHgcmvQry6kJhL--