public inbox for [email protected]
help / color / mirror / Atom feedFrom: Pavel Stehule <[email protected]>
To: Marcos Pegoraro <[email protected]>
Cc: Dmitry Dolgov <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Erik Rijkers <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: DUVAL REMI <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: proposal: schema variables
Date: Wed, 20 Nov 2024 14:52:16 +0100
Message-ID: <CAFj8pRCaFzRKWx3y64RQzw1-Jb8g4-LPu3b5byH9=us5JTRGgg@mail.gmail.com> (raw)
In-Reply-To: <CAB-JLwZfrsXZVOVVANieoPixKVRc_4HORVbkCPoSOLJe4DNXLw@mail.gmail.com>
References: <[email protected]>
<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>
Hi
st 20. 11. 2024 v 14:29 odesílatel Marcos Pegoraro <[email protected]>
napsal:
> Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule <
> [email protected]> escreveu:
>
>> I wrote POC of VARIABLE(varname) syntax support
>>
>
> Not related with POC of VARIABLE but seeing your patches ...
>
> Wouldn't it be better to use just one syntax and message for what to do ON
> COMMIT ?
>
> When creating a new variable you use
> CREATE VARIABLE ... ON COMMIT DROP | ON TRANSACTION END RESET
>
> On PSQL \dV+ you show
> Transactional end action
>
> Maybe all them could be just ON COMMIT
> CREATE VARIABLE ... [ON COMMIT {NO ACTION, DROP, RESET}] and \dV+ just "on
> commit" on title column
>
ON COMMIT DROP is related to temporary objects. In this case, you don't
need to think about ROLLBACK, because in this case, the temp objects are
removed implicitly.
ON TRANSACTION END RESET can be used for non temporary objects too. So this
is a little bit of a different feature. But the reset is executed if the
transaction is ended by ROLLBACK too. So using a syntax just ON COMMIT can
be a little bit messy. TRANSACTION END is more intuitive, I think. If I
remember there was a proposal ON COMMIT OR ROLLBACK, but I think
TRANSACTION END is better and more intuitive, and better describes what is
implemented. I can imagine to support clauses ON COMMIT RESET or ON
ROLLBACK RESET that can be used independently, but for this time, I don't
want to increase a complexity now - reset is just at transaction end
without dependency if the transaction was committed or rollbacked.
Regards
Pavel
> regards
> Marcos
>
view thread (439+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: proposal: schema variables
In-Reply-To: <CAFj8pRCaFzRKWx3y64RQzw1-Jb8g4-LPu3b5byH9=us5JTRGgg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox