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 1tAC6u-00EGxv-IH for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Nov 2024 17:52:28 +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 1tAC6r-007vjC-NE for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Nov 2024 17:52:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tAC6r-007viu-Bm for pgsql-hackers@lists.postgresql.org; Sun, 10 Nov 2024 17:52:25 +0000 Received: from mail-yb1-xb2a.google.com ([2607:f8b0:4864:20::b2a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tAC6k-001EDv-N3 for pgsql-hackers@lists.postgresql.org; Sun, 10 Nov 2024 17:52:25 +0000 Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-e30d821c3e0so3565030276.1 for ; Sun, 10 Nov 2024 09:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731261138; x=1731865938; 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=WABgJ0shkQOPXYFM9DjMCTTeKkm83UBj87oSnwj3mH0=; b=cUs/b6OtoF4HO9HEBicCd93/843DGWDssJxcFRBZ10x8mHU2B86PxiRkzmCX3In5LN vGIvSaY7vOwWVvmjVyH/zaJa6ouQ0JI8iXibGxNiTQJb65Rk0SHwkkGwiNcD7mcFCXIo wvOedkdExIFgpDcGcMno7zNyAC0a2C1fQf3+6z7SuFuqhGFIySaqqI7JH3MvcQXvZC3c Mytjj17rZ7AxTeAPN/ixLRXPr6IYo1Xy2NMYOYtqacT169yklh5WFW1yJryD51X9pPCn CaGPuLcp2wXW/QFoMhF5/FOVu+8lENRa21xCKON+0XJCrHMrWIR1H4f9LEAUCrga5gTo OY7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731261138; x=1731865938; 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=WABgJ0shkQOPXYFM9DjMCTTeKkm83UBj87oSnwj3mH0=; b=GIpbkqSEGO5Tg1Bi4CVa3iMKSdbxJFTPNeYwn5d24K3d5byiikFQI6gNErs/r/1lFP xKT2Yj3FePafvCwDurFBo2Ih0gw6hwSxi+VI445Zuc7Pn4TEH3Y0s9wj0+4hAgs5gMOX AoUaCrqrklaN5NtdgKFChBf0rKQRmYMwRu7ohk+8bLf67VP0PmWQFnsfpiDPmIp9joaz UTMi+DL8ogPvJ3CWBopusXuvwXLIFBSyaXlaQ7Ij+ev+cmrXeAqk/AUyEpuJt73bZQw+ w6yqgv/93UnjORS3e5NX0B/DRoXVQVwAixmPYZVL9Lrh4q8Kd1b69AwHe1rmjRaTOhiK dfvw== X-Forwarded-Encrypted: i=1; AJvYcCUVVHtwK0t5Tsq7/eEeqtnM+V6SLpoC5axqWxpBDoT1a5QyT1RsaQh+kZHG4tihwERKGw/EdHfH6p6uURHR@lists.postgresql.org X-Gm-Message-State: AOJu0YyQhrx8ZChE6QbCtGHXfvUZyym8UQn95FrP1QqFUW7xfSdLrzs0 mqodWiXAmgaTmaPLZJlRjZD74BOL4Jm5JpQCQMje0MQDWLX2heRYyXCOuCT6e+KzEUCq1XKqBmX EPNlTz7CQspFBFpnql4oP2A1xdkw= X-Google-Smtp-Source: AGHT+IHQ81Hs3xAoV366LpA/6ON+mvjhHgXpZUbXRNxcIc/cgDVxzb5Kn/I0BUFnikZqJitp8iGlGhxxVLkFzhyo5hQ= X-Received: by 2002:a05:6902:340c:b0:e30:da65:723c with SMTP id 3f1490d57ef6-e337f8dffc4mr8221607276.45.1731261138092; Sun, 10 Nov 2024 09:52:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Stehule Date: Sun, 10 Nov 2024 18:51:40 +0100 Message-ID: Subject: Re: proposal: schema variables To: Dmitry Dolgov <9erthalion6@gmail.com> Cc: Laurenz Albe , Erik Rijkers , Michael Paquier , Amit Kapila , DUVAL REMI , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000264b11062692a5a8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000264b11062692a5a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ne 10. 11. 2024 v 17:19 odes=C3=ADlatel Pavel Stehule napsal: > > > ne 10. 11. 2024 v 16:24 odes=C3=ADlatel Dmitry Dolgov <9erthalion6@gmail.= com> > napsal: > >> Hi folks, >> >> Thanks for continuing this work. As a side note, I would like to mention >> how strange the situation in this CF item is. If I understand correctly, >> there are two hackers threads discussing the same patch, with recent >> patches posted in both of them. This is obviously confusing, e.g. the >> main concern from another thread, about names clashing, wasn't even >> mentioned in this one. Is it possible to reconcile development in one >> thread? >> > > This is probably my error. I don't try to organize threads, just I'll try > to reply in the thread where I got a question. > I thought a lot of time about better solutions for identifier collisions and I really don't think so there is some consistent user friendly syntax. Personally I think there is an easy already implemented solution - convention - just use a dedicated schema for variables and this schema should not be in the search path. Or use secondary convention - like using prefix "__" for session variables. Common convention is using "_" for PLpgSQL variables. I searched how this issue is solved in other databases, or in standard, and I found nothing special. The Oracle and SQL/PSM has a concept of visibility - the variables are not visible outside packages or modules, but Postgres has nothing similar. It can be emulated by a dedicated schema without inserting a search path, but it is less strong. I think we can introduce an alternative syntax, that will not be user friendly or readable friendly, but it can be without collisions - or can decrease possible risks. It is nothing new - SQL does it with old, "new" syntax of inner joins, or in Postgres we can where salary < 40000 or where pg_catalog.int4lt(salary, 40000); or some like we use for operators OPERATOR(*schema*.*operatorname*) So introducing VARIABLE(schema.variablename) syntax as an alternative syntax for accessing variables I really like. I strongly prefer to use this as only alternative (secondary) syntax, because I don't think it is friendly syntax or writing friendly, but it is safe, and I can imagine tools that can replace generic syntax to this special, or that detects generic syntax and shows some warning. Then users can choose what they prefer. Two syntaxes - generic and special can be good enough for all - and this can be perfectly consistent with current Postgres. Regards Pavel > Regards > > Pavel > > --000000000000264b11062692a5a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
ne 10. 11. 2024 v=C2=A017:19 odes=C3= =ADlatel Pavel Stehule <pavel= .stehule@gmail.com> napsal:


ne 10. 11. 2024 v= =C2=A016:24 odes=C3=ADlatel Dmitry Dolgov <9erthalion6@gmail.com> napsal:
Hi folks,

Thanks for continuing this work. As a side note, I would like to mention how strange the situation in this CF item is. If I understand correctly, there are two hackers threads discussing the same patch, with recent
patches posted in both of them. This is obviously confusing, e.g. the
main concern from another thread, about names clashing, wasn't even
mentioned in this one. Is it possible to reconcile development in one
thread?

This is probably my error. I do= n't try to organize threads, just I'll try to reply in the thread w= here I got a question.

I = thought a lot of time about better solutions for identifier collisions and = I really don't think so there is some consistent user friendly syntax. = Personally I think there is an easy already implemented solution - conventi= on - just use a dedicated schema for variables and this schema should not b= e in the search path. Or use secondary convention - like using prefix "= ;__" for session variables. Common convention is using "_" f= or PLpgSQL variables. I searched how this issue is solved in other database= s, or in standard, and I found nothing special. The Oracle and SQL/PSM has = a concept of visibility - the variables are not visible outside packages or= modules, but Postgres has nothing similar. It can be emulated by a dedicat= ed schema without inserting a search path, but it is less strong.
=

I think we can introduce an alternative syntax, that wi= ll not be user friendly or readable friendly, but it can be without collisi= ons - or can decrease possible risks.

It is nothin= g new - SQL does it with old, "new" syntax of inner joins, or in = Postgres we can 
where salary < 4=
0000 
or

where pg_catalog.int4lt(salary, 40000=
);

or some like we use for operators OPERATOR(schema.operatorname= )

So introducing VARIABLE(schema.variablename) syntax as an alternative s= yntax for accessing variables I really like. I strongly prefer to use this = as only alternative (secondary) syntax, because I don't think it is fri= endly syntax or writing friendly, but it is safe, and I can imagine tools t= hat can replace generic syntax to this special, or that detects generic syn= tax and shows some warning. Then users can choose what they prefer. Two syn= taxes - generic and special can be good enough for all - and this can be pe= rfectly consistent with current Postgres.

Regards<= /div>

Pavel

<= div>
Regards

Pavel
=C2= =A0
--000000000000264b11062692a5a8--