Date: Sat, 6 Nov 2021 09:57:14 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
	Jaime Casanova <jcasanov@systemguards.com.ec>,
	Erik Rijkers <er@xs4all.nl>, Gilles Darold <gilles@darold.net>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Michael Paquier <michael@paquier.xyz>,
	Amit Kapila <amit.kapila16@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>
Subject: Re: Schema variables - new implementation for Postgres 15
Message-ID: <20211106145714.GI17618@telsasoft.com>
References: 
 <CAFj8pRCQX+Cry7kN8CDGgpKF2Zmd_vNafzRb-9bhR8bgoZqpGA@mail.gmail.com>
 <CAFj8pRD5Hy8Os-hTtw7FSJrHDx3QW6ohKyM+R0DVCH-Fi1G8-A@mail.gmail.com>
 <b8c690e9-67f7-b017-fade-d3d0bb03f891@xs4all.nl>
 <CAFj8pRDfJ4nC7MV2jK=E63_9M7Bf6+qP1sSYYQuEekWpCzbMNA@mail.gmail.com>
 <20210912021338.GA21136@ahch-to>
 <CAFj8pRA-y9aTVwYPuVcdLpeb1F5M4n_mDmz-eec3ipJsC79GeA@mail.gmail.com>
 <CAFj8pRDN+B4OWkcanLa82BpqJqePEFcTzvu=pJFu=z+aTb9EXg@mail.gmail.com>
 <CAFj8pRAPcF7u_rV_2p=vaGFf8UkW1-Z7kef4rTFpsgy8JROH_w@mail.gmail.com>
 <68eedf25-79ca-d0e7-1af6-bad225fdcd97@enterprisedb.com>
 <CAFj8pRAJ1H0sOAsOVK_+4fXyXTjQ+GcL+NoTPiuDDYy+V8TFYQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAFj8pRAJ1H0sOAsOVK_+4fXyXTjQ+GcL+NoTPiuDDYy+V8TFYQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20211106145714.GI17618%40telsasoft.com>
Precedence: bulk

On Sat, Nov 06, 2021 at 04:45:19AM +0100, Pavel Stehule wrote:
> st 3. 11. 2021 v 14:05 odesílatel Tomas Vondra <tomas.vondra@enterprisedb.com> napsal:
> > 1) Not sure why we need to call this "schema variables". Most objects
> > are placed in a schema, and we don't say "schema tables" for example.
> > And it's CREATE VARIABLE and not CREATE SCHEMA VARIABLE, so it's a bit
> > inconsistent.

+1

At least the error messages need to be consistent.
It doesn't make sense to have both of these:

+               elog(ERROR, "cache lookup failed for schema variable %u", varid);
+               elog(ERROR, "cache lookup failed for variable %u", varid);

> Yes, there is inconsistency, but I think it is necessary. The name
> "variable" is too generic. Theoretically we can use other adjectives like
> session variables or global variables and the name will be valid. But it
> doesn't describe the fundamentals of design. This is similar to the
> package's variables from PL/SQL. These variables are global, session's
> variables too. But the usual name is "package variables". So schema
> variables are assigned to schemes, and I think a good name can be "schema
> variables". But it is not necessary to repeat keyword schema in the CREATE
> COMMAND.
> 
> My opinion is not too strong in this case, and I can accept just
> "variables" or "session's variables" or "global variables", but I am not
> sure if these names describe this feature well, because still they are too
> generic. There are too many different implementations of session global
> variables (see PL/SQL or T-SQL or DB2).

I would prefer "session variable".

To me, this feature seems similar to a CTE (which exists for a single
statement), or a temporary table (which exists for a single transaction).  So
"session" conveys a lot more of its meaning than "schema".

But don't rename everything just for me...

-- 
Justin