MIME-Version: 1.0
References: <afb4e296d7ce57986f23bcfdee39b259b8f85f56.camel@cybertec.at>
 <CAFj8pRAjU-X6rEE9=1++PdtXOPc2uo=yu-tcFXByi-kN3B_7Vw@mail.gmail.com>
 <CAFj8pRC+hPCc2X88xC=pTJoqmVPApDsageZOMyqaxi5788WxHA@mail.gmail.com>
 <CAFj8pRDJ9cq00VYSHxs6LsoHNWjhYXyWWBtV6UgeWwhs0AHa9A@mail.gmail.com>
 <CAFj8pRBPXTcw_3fpKtgVthV2+9rZGhxitZ40DnAwCrK601TZZg@mail.gmail.com>
 <ndtfl4tsnpkb7m7hwvnmlpsascpgd3a7xvjmjhtxffsbrgygtm@4du6zsmnnwq5>
 <CAFj8pRAu4XvNCGu1751t=2YEqLqTjDA3FavMExm2S0KYQq=DdQ@mail.gmail.com>
 <CAFj8pRAsEoeZv0HEnA8CKgFKDSQ-wYw18Os1vdksWCV7ez2bVw@mail.gmail.com>
 <3chredgnjcmccym2kczawfih226b4ac6co7p6z4jeofevrcosi@mrsxkx2x2c65>
 <CAFj8pRBoWPDTOwn5FmMzc+1qiopw+N04U26nviOdF61fs8A2wQ@mail.gmail.com>
 <stckyvkl4yyzvgjsaawojs3xikke7mmds5bhv7l7qerclywywk@h4v4n43xm6u2>
 <78f3c264-658a-4007-ab79-4cc913fba675@technowledgy.de>
In-Reply-To: <78f3c264-658a-4007-ab79-4cc913fba675@technowledgy.de>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Sat, 16 Nov 2024 16:36:19 +0100
Message-ID: 
 <CAFj8pRCeh3u9rSqq0me52iik9+pNUvYeb8OgbuFxJArrb4VDjA@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Wolfgang Walther <walther@technowledgy.de>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>,
 Laurenz Albe <laurenz.albe@cybertec.at>,
	Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>,
	Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000004295f706270974d4"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRCeh3u9rSqq0me52iik9%2BpNUvYeb8OgbuFxJArrb4VDjA%40mail.gmail.com>
Precedence: bulk

--0000000000004295f706270974d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

so 16. 11. 2024 v 15:56 odes=C3=ADlatel Wolfgang Walther <walther@technowle=
dgy.de>
napsal:

> Dmitry Dolgov:
> > This sounds to me like an argument against allowing name clashing betwe=
en
> > variables and tables. It makes even more sense, since session variables
> are in
> > many ways similar to tables.
>
> +1
>

It doesn't help too much, because the unique tuple (schema, name), and
there is a search path.

Secondly, the pg_class is not good enough for description of scalar
variables, and enhancing pg_class for scalar variables can be messy.


>
> My mental model of a session variable is similar to a single-row,
> optionally global temporary, table.
>
> Is there any substantial difference that I am not aware of?
>

What I know, the variables are used as query parameters, not as relations -
Oracle, DB2, MSSQL, MySQL, ...

semantically, yes - it is a global temporary object, but  it can be scalar
or composite value - it is not row.

(global (temp)) table can hold 0, 1 or more rows (and rows are always
composite of 0..n fields). The variable holds a value of some type.
Proposed session variables are like plpgsql variables (only with different
scope). In Postgres there is a difference between a scalar variable and
composite variable with one field.

Regards

Pavel


> Best,
>
> Wolfgang
>

--0000000000004295f706270974d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">so 16. 11. 2024 v=C2=A015:56 odes=C3=
=ADlatel Wolfgang Walther &lt;<a href=3D"mailto:walther@technowledgy.de">wa=
lther@technowledgy.de</a>&gt; napsal:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Dmitry Dolgov:<br>
&gt; This sounds to me like an argument against allowing name clashing betw=
een<br>
&gt; variables and tables. It makes even more sense, since session variable=
s are in<br>
&gt; many ways similar to tables.<br>
<br>
+1<br></blockquote><div><br></div><div>It doesn&#39;t help too much, becaus=
e the unique tuple (schema, name), and there is a search path.</div><div><b=
r></div><div>Secondly, the pg_class is not good enough for description of s=
calar variables, and enhancing pg_class for scalar variables can be messy.<=
br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
<br>
My mental model of a session variable is similar to a single-row, <br>
optionally global temporary, table.<br>
<br>
Is there any substantial difference that I am not aware of?<br></blockquote=
><div><br></div><div>What I know, the variables are used as query parameter=
s, not as relations - Oracle, DB2, MSSQL, MySQL, ...</div><div><br></div><d=
iv>semantically, yes - it is a global temporary object, but=C2=A0 it can be=
 scalar or composite value - it is not row.</div><div><br></div><div>(globa=
l (temp)) table can hold 0, 1 or more rows (and rows are always composite o=
f 0..n fields). The variable holds a value of some type. Proposed session v=
ariables are like plpgsql variables (only with different scope). In Postgre=
s there is a difference between a scalar variable and composite variable wi=
th one field. <br></div><div><br></div><div>Regards</div><div><br></div><di=
v>Pavel<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
<br>
Best,<br>
<br>
Wolfgang<br>
</blockquote></div></div>

--0000000000004295f706270974d4--