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>
 <CAFj8pRB_E1GM_YGT-ti4bXka6mhLdAAFeTe+BHgHFYC+qb-76g@mail.gmail.com>
 <CAB-JLwZfrsXZVOVVANieoPixKVRc_4HORVbkCPoSOLJe4DNXLw@mail.gmail.com>
 <CAFj8pRCaFzRKWx3y64RQzw1-Jb8g4-LPu3b5byH9=us5JTRGgg@mail.gmail.com>
In-Reply-To: 
 <CAFj8pRCaFzRKWx3y64RQzw1-Jb8g4-LPu3b5byH9=us5JTRGgg@mail.gmail.com>
From: Marcos Pegoraro <marcos@f10.com.br>
Date: Wed, 20 Nov 2024 11:14:55 -0300
Message-ID: 
 <CAB-JLwYMw1pORoZxA9XeR52Svps6ah=ATgRDHdGQBT+j+Uy7qQ@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Pavel Stehule <pavel.stehule@gmail.com>
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="00000000000072d3e6062758c862"
Archived-At: 
 <https://www.postgresql.org/message-id/CAB-JLwYMw1pORoZxA9XeR52Svps6ah%3DATgRDHdGQBT%2Bj%2BUy7qQ%40mail.gmail.com>
Precedence: bulk

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

Em qua., 20 de nov. de 2024 =C3=A0s 10:52, Pavel Stehule <pavel.stehule@gma=
il.com>
escreveu:

> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
> think.
>
>>
Exactly to be not messy I would just ON COMMIT for all, and DOCs can
explain that this option is ignored for temp objects and do the same at the
end of transaction, independently if commited or rolled back

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Em qua., 20 de nov. de 2024 =C3=A0s =
10:52, Pavel Stehule &lt;<a href=3D"mailto:pavel.stehule@gmail.com">pavel.s=
tehule@gmail.com</a>&gt; escreveu:</div></div><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>COMMI=
T can be a little bit messy. TRANSACTION END is more intuitive, I think. </=
div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"font-family=
:verdana,sans-serif;color:rgb(102,102,102)"></div></div></div></blockquote>=
</div></div></blockquote><div><br></div><div class=3D"gmail_default" style=
=3D"font-family:verdana,sans-serif;color:rgb(102,102,102)">Exactly to be no=
t messy I would just ON COMMIT for all, and DOCs can explain that this opti=
on is ignored for temp objects and do the same at the end of transaction, i=
ndependently if commited or rolled back</div></div></div>

--00000000000072d3e6062758c862--