Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uHTaS-002yDt-QQ for pgsql-hackers@arkaria.postgresql.org; Tue, 20 May 2025 20:29:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uHTaQ-008iQe-MM for pgsql-hackers@arkaria.postgresql.org; Tue, 20 May 2025 20:29:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uHTaP-008iQV-P0 for pgsql-hackers@lists.postgresql.org; Tue, 20 May 2025 20:29:18 +0000 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uHTaK-002oyX-1q for pgsql-hackers@lists.postgresql.org; Tue, 20 May 2025 20:29:14 +0000 Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e7ba2583e10so2295657276.0 for ; Tue, 20 May 2025 13:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747772951; x=1748377751; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YQmATXbmXvsBXpl4BodPGVEmdAiDXHmnl9nyyqf8J4M=; b=c99pL/qHQVoB4oKtsV9Sm5CaYrkPOPKVFdEWSHMfhgF28n44GUZgjtRTyBbSX2wULN ikOoiqr5kJH/2ynDEODmvhyhjnCaR2P80mLIEa6PLnuo2ziAE5CPr3JZ2YoOeWLqeJ4d KqsD7s51zMqGmRn1fa+DIJkJdUQNqFwGZN+ZmCUrEB/2lK3Kmq7n6gJ7hlvxAVrxHofZ fceZeQq5MBXRFLD54fQ324T94J0X/os8+4+f0iRMuMYHuFmmzbhYsNgR7vno1Dx6WCW9 qqoZMCeqfrpmc6K8XGMhDxhGlQ6vfTYXpfWz2ok6iV15+Ixa/LcdaA+0O5Iv1b/ILdU3 nsLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747772951; x=1748377751; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YQmATXbmXvsBXpl4BodPGVEmdAiDXHmnl9nyyqf8J4M=; b=M/lQvliRxg6KPeh/JYfuY2canIpq9ketWpktxCpvS1qUb1G7/kIY/yoCZMBy61qPi9 ckbVJ5iwlMAol8wBmV+bJvkqbc8UygCDbI/Q3acsbNZl+SKAqYh84mQPoBrAepbBmX2r Mu7/6elrHBy8hfq/ahjF88URB0k0JwdkpexFDVMu/U7IJbDo5DeSme+8DMvzsxSd1DQ/ A8VTYVIcnCZYS2aiufOPOqR3W2sK1kmiTuZ6XsQ+zIqNMGILxkcdUWsvNf/xd+5mZE2M 5wsPst2DAbHfNIbVFq3QFDR+FmXlvfeSWl7vKbix6XM45/1nKDq5Ay1zoH0HDEL2WdIs z8+w== X-Forwarded-Encrypted: i=1; AJvYcCWR769YRQZiDDIBuzGw47u7Jcz+8TnS4Y8DBR4bi9ylkOnvxoCOHz1DcZinJzyOSoFztMKa8S+4rhF2Lr3e@lists.postgresql.org X-Gm-Message-State: AOJu0YwfxW5k5nk8AThxPzl0ZeTDFuWmpxBjv+rm/c8DIZBgs15x90CU goAD/eE+isO6PBooHRVDL6r10O2O2O1cRlmOxTKBfbBeELU0l2FMOS/i6yubHAx9oSyHSSsPnSi a84LIoRdvUW/F1XlvUc4wlE617AkL8NE= X-Gm-Gg: ASbGncs3zLDNJc3F2+p+F+7GKuIojyDK9gX8YJeh5BLuzi9DIWgMkulArIzbjAcErux rb+Aw1HRgTdDn/cAKHkvnPxVnZPcancHD1arrLL0I6cIOUPXw7eWMoNMlgffhlGC739Rv0G5MPZ 0rjeZCAmsMdLtOrdYs3sG83A7XLpozn2AjQ33bVwMH/q7f2CC0TsOp5Sw2wzBgrXN3GA== X-Google-Smtp-Source: AGHT+IHbDOpdJKQAZl4F4MyzexokLAGdFGgFCr0eUIy4+eNWEeiIteriL6ImzyDfTgERcBcuFjqlET9UnO/tvZTtgAI= X-Received: by 2002:a05:6902:2683:b0:e7b:e998:687e with SMTP id 3f1490d57ef6-e7be99869c5mr12680710276.3.1747772951419; Tue, 20 May 2025 13:29:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Stehule Date: Tue, 20 May 2025 22:28:31 +0200 X-Gm-Features: AX0GCFvuZ1S54RVATzIJp0D9q6mLvuQorPg28AiJhsgiZ_6qdTbRiFUIk9zy8yY Message-ID: Subject: Re: Re: proposal: schema variables To: Bruce Momjian Cc: Marcos Pegoraro , jian he , Dmitry Dolgov <9erthalion6@gmail.com>, Laurenz Albe , Erik Rijkers , Michael Paquier , Amit Kapila , DUVAL REMI , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000eade2a0635971952" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000eade2a0635971952 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C3=BAt 20. 5. 2025 v 18:39 odes=C3=ADlatel Bruce Momjian napsal: > On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote: > > Em ter., 20 de mai. de 2025 =C3=A0s 11:56, Bruce Momjian > > escreveu: > > > > I will again ask why this patch set is being reposted when there is > no > > plan to apply it to git master > > > > Too bad. I would love to have this functionality, from the user's point > of view > > there are problems where it would solve them wonderfully. I don't know > > technically of what prevents it from being natively on core, but it > would be > > great, it would definitely be. > > My only point is that we should only be using email lists for work that > is being actively worked on to be added to community Postgres. There > has been talk of a trimmed-down version of this being applied, but I > don't see any work in that direction. > I sent a reduced version a few months ago - from 21 patches to 8 (and it can be reduced to six if we postpone tools for detection ambiguity). The timing was not perfect - the focus was and it is concentrated to finish pg18. I am very sorry if this topic and patches bother anyone. I am afraid if I close it to some personal github, it will not be visible, and I am sure thi= s feature is missing in Postgres. Today we have few workarounds. Some workarounds are not available everywhere, some workarounds cannot be used for security. With integrated solutions some scenarios can be done more easily, more secure, faster, more comfortable. It is true, so mentioned scenarios are not "hot" today. Stored procedures or RLS or migration procedures from other databases are not extra common. But who uses it, then he misses session variables. 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. Regards Pavel > > This patch should be moved to a separate location where perhaps people > can subscribe to updates when they are posted, perhaps github. > > -- > Bruce Momjian https://momjian.us > EDB https://enterprisedb.com > > Do not let urgent matters crowd out time for investment in the future. > --000000000000eade2a0635971952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

=C3=BAt 20. 5. 2025 v=C2=A018= :39 odes=C3=ADlatel Bruce Momjian <b= ruce@momjian.us> napsal:
On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro w= rote:
> Em ter., 20 de mai. de 2025 =C3=A0s 11:56, Bruce Momjian <bruce@momjian.us>
> escreveu:
>
>=C2=A0 =C2=A0 =C2=A0I will again ask why this patch set is being repost= ed when there is no
>=C2=A0 =C2=A0 =C2=A0plan to apply it to git master
>
> Too bad. I would love to have this functionality, from the user's = point of view
> there are problems where it would solve them wonderfully. I don't = know
> technically of what prevents it from being natively on core, but it wo= uld be
> great, it would definitely be.

My only point is that we should only be using email lists for work that
is being actively worked on to be added to community Postgres.=C2=A0 There<= br> has been talk of a trimmed-down version of this being applied, but I
don't see any work in that direction.

I sent a reduced version a few months ago - from 21 patches to 8 (and it= can be reduced to six if we postpone tools for detection=C2=A0ambiguity).<= /div>
The timing was not perfect - the focus was and it is concentrated= to finish pg18.

I am very sorry if this topi= c and patches bother anyone. I am afraid if I close it to some personal git= hub, it will not be visible, and I am sure this
feature is missin= g in Postgres. Today we have few workarounds. Some workarounds are not avai= lable everywhere, some workarounds cannot
be used for security. W= ith integrated solutions some scenarios can be done more easily, more secur= e, faster, more comfortable.=C2=A0 It is true, so
mentioned scena= rios are not "hot" today. Stored procedures or RLS or migration p= rocedures from other databases are not extra common. But
who uses= it, then he misses session variables.

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 almo= st 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),=C2=A0
and it is consistent wi= th Postgres. There are more ways to reduce risk of unwanted ambiguity to ze= ro. But it increases the size of the patch.

R= egards

Pavel





=C2=A0

This patch should be moved to a separate location where perhaps people
can subscribe to updates when they are posted, perhaps github.

--
=C2=A0 Bruce Momjian=C2=A0 <bruce@momjian.us>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://momjian.us=
=C2=A0 EDB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:= //enterprisedb.com

=C2=A0 Do not let urgent matters crowd out time for investment in the futur= e.
--000000000000eade2a0635971952--