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 1tYoL3-00FTtM-QX for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Jan 2025 15:32:50 +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 1tYoL2-000TOg-GD for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Jan 2025 15:32:48 +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 1tYoL2-000TNN-1u for pgsql-hackers@lists.postgresql.org; Fri, 17 Jan 2025 15:32:48 +0000 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tYoL0-0002dA-0J for pgsql-hackers@lists.postgresql.org; Fri, 17 Jan 2025 15:32:47 +0000 Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-e549dd7201cso3880529276.0 for ; Fri, 17 Jan 2025 07:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737127965; x=1737732765; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=8NeBzv5nC/QIPAWgvZo/h5iEx/3DIP5OajajqRdrlf4=; b=UiiLDB36/Oc3yjSzwV1WyCXtDoRdove5wIkKMcZiTtLNCuFzhpgvzk0UTEtoxF8xMa FC/Eb2baShfbWtVNJmcRp0c8MfcVjlacs6GcZvX2IUVFp24iLGOH84r8Pw6+3gbki7vD pguZJfOpi7yqHIDf+0GGJaUniaBSY1xMGc6k925jZt3YJwYBAGKIZgpOicApdETjQhu7 jI2rGkh021sfI0i1KbYFc3Zwd1s+uzREKLTHW6EqA6E/oUg0zoNla4TqPeZPiXesruS6 lUTiXbM7OA6yCilgEguqrqmeifIomy5ACCdqfxjgwzgftwdA0/qTsFHSQxVqMdQvGfv1 2wuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737127965; x=1737732765; h=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=8NeBzv5nC/QIPAWgvZo/h5iEx/3DIP5OajajqRdrlf4=; b=F0PwLCJDPXSAb6eDfMpeoWDD1anz2fwNzqY9nq8sha6aUzJHnG4bsXNo3ZDKA1G+5K mmuxmg0aM0hXFEnPtqO0RiU9mfhwGuks1mn5u1yb6SnrIc07n4PtVbuMFMQXkq1Xghw0 HX3CJntAeeTZEpR9LCAhNjQUReEuU/w1f6c/Jb870P2zjugCd2tFMoC2RUq4fEqpTLQ0 uq6sPlerlrekB1qbiKgsHWNt9B4eM2Y9/7F+nQrDCZoLTv3mm5GA8HJtKEeVuu1CZxGO +H6i18RAdGXtjMMUNibGFk+EcQdffKVBkMNS6/wFl0/6Pmgutd6u5h6rhRqFwUvK2ZzM jAqw== X-Forwarded-Encrypted: i=1; AJvYcCWkf/4+wR5lMf3dWigiuNZS3LLIXgKKukWtr5JABxoUiuvGnz/L4D8TBqFbEBuwX/3+ibF1osuz+aKVVGP5@lists.postgresql.org X-Gm-Message-State: AOJu0YwZptr3QHuXc+r1Oa8g/FeTeHUEhAZidohb+HJwk7X1nP0TC1MA 6f/7HNlYEA1kFTj8ffO7R4y7jEzs7jboQWQ9lCzJGfBuqEQbadXfM8tsExnbd4peDsjany2Y5mM 4r1nOiiQ24x1c4s5Yx6a47W8N5XE= X-Gm-Gg: ASbGnctKWYSNpRdpENPsH9TeRmZdBiu0QyAR6KSyvHUvrb2iIUNUeCSTQLoVHFZA3Ib /b5JANSthsM3K3WN5J+5WohagR4tboOciY+PQSYC7VrrPLWnoSzUDUPqp5AxSN37z49zg3Ys= X-Google-Smtp-Source: AGHT+IFBoeHwjpsTpGGD6LfIZhsgiJpD2lKHHL29QtvNRwPSql4tKiysM/g3Caw5RzWSxQIZNSlXhGAcobpv4vbWHf0= X-Received: by 2002:a05:6902:1793:b0:e57:590e:c48a with SMTP id 3f1490d57ef6-e57b1364cf6mr1740130276.42.1737127965625; Fri, 17 Jan 2025 07:32:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Stehule Date: Fri, 17 Jan 2025 16:32:07 +0100 X-Gm-Features: AbW1kvbJ4cTRumsDi-FlyBiYx241gpBI4xiu1cjUvKjOoPyZ1s3DnMrZ-FHMtJg Message-ID: Subject: Fwd: Re: proposal: schema variables To: Bruce Momjian , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000521bfd062be89f30" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000521bfd062be89f30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi p=C3=A1 17. 1. 2025 v 15:39 odes=C3=ADlatel Bruce Momjian napsal: > On Fri, Jan 17, 2025 at 03:28:55PM +0100, Pavel Stehule wrote: > > Dne p=C3=A1 17. 1. 2025 15:16 u=C5=BEivatel Bruce Momjian > 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 w= e > 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 https://momjian.us > EDB https://enterprisedb.com > > Do not let urgent matters crowd out time for investment in the future. > > > --000000000000521bfd062be89f30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi

p=C3=A1 17. 1. 2025 v=C2=A015:39 od= es=C3=ADlatel Bruce Momjian <bruce@momjian.us> napsal:
On Fri, Jan 17, 2025 at 03:28:55PM +0100, Pave= l Stehule wrote:
> Dne p=C3=A1 17. 1. 2025 15:16 u=C5=BEivatel Bruce Momjian <bruce@momjian.us> nap= sal:
>=C2=A0 =C2=A0 =C2=A0Is this really something we are considering applyin= g, since it has been
>=C2=A0 =C2=A0 =C2=A0around for years?=C2=A0 I am unclear on that and we= had better know if we are
>=C2=A0 =C2=A0 =C2=A0going to continue reviewing this.
>
> I hope so it is possible, minimally in some basic form. And i think so= there
> was real good=C2=A0 progres of quality in last three months.=C2=A0

I am not asking if it is improving.=C2=A0 I am asking if it is a desired feature;=C2=A0 see:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://wiki.po= stgresql.org/wiki/Todo#Development_Process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 201= 7 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 sho= uld 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 var= iables. I found a good solution at the end of=C2=A0 2022. It is true, so ti= me has changed
from this time, and Postgres and people are differ= ent. In this time the migration from Oracle was stronger
topic.

If you read all the discussion, you can find mo= re times the sentence so this can be a good feature (not from me).
Surely the session variables can be implemented differently - minimally t= here are four different implementations
mssql, db2, mysql and ora= cle, 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 p= ossibility to set access
rights so the workaround cannot be secur= ed.

There is one stronger argument for session var= iables - we are missing global temporary tables. It is a real
lim= it and more times I found users with bloated pg_class, pg_attributes due us= ing 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 tabl= es, 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
<= div>



=C2=A0
<= /div>

--
=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.


--000000000000521bfd062be89f30--