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 1tDl8r-002zgf-89 for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 13:53:13 +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 1tDl8p-005qmN-8e for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 13:53:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDl8o-005qmF-Q5 for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 13:53:10 +0000 Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDl8b-002swe-6v for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 13:53:09 +0000 Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-e382589e8fdso5077071276.0 for ; Wed, 20 Nov 2024 05:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732110776; x=1732715576; 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=AsUxeTFpcovQW4X+hDdRWTJ1PyDvcYcC4ADxMR1t3sA=; b=NdpKUvwdaxsxIB9sX+yKKfe5jfDcW6M9mZd2GxYDBFT0nB0JTuZ00B8q82M6iz0G55 E1qfeVQ3CIT21OmJUHK1mhqiZ4mqcvv4gUU7wXhLpQaouoO5U10vaarEeO8DPEGIZ73i z3THvPQALkV++QBDKt6eg/CKibe5fVbcG8pGLLRVvHARDOHAmR4VdEshbglsgRjOxYx8 w0U+CwqYHIdbh8act6Ra62Gzacl/xCK8TUkf/yRdYp1bpyzM1r5ImzMLg/TEB9jVcHNd My7ZlCkVHcasE7kG4LOWzedK/4QxmKZrQzlgNez9Wo2o9frfAIJ3Fnd0iKi2JJWuJqJz Wc0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732110776; x=1732715576; 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=AsUxeTFpcovQW4X+hDdRWTJ1PyDvcYcC4ADxMR1t3sA=; b=SLMaSFw/bUVgjho5/+EawQj/TH3z+PsXlc7uZO+PHFc0E8mS1PDoMG1FlNZibuTFxw s3dOz0W1Cey2v5SW3MZcmR9IG+OxjwsgpkFzHCjSMwDSZ+PdpEz4TOlqUvGfYWX5a1rz ugkCIzvG0puRm6pV6E6m3VJSLm8M/J3i6XOU5771MfzK4kxHUfVxFdpc840jjjigh62+ 2VprqNOv/o+NBWeJ9wW3+apl2DvCY2ZHFivNJC4aSbMse+Z+tVlnjiCugqqa9zF88Myo NJQsePXB+ygOj3ZHMBUwY2LKqloZAIhDeLBAMVs2AAQrEILNDfgumm2XdT99LiIFQUp0 qMNQ== X-Forwarded-Encrypted: i=1; AJvYcCWI1v7WfBpQg//bvFUpMsR8Ag83neWufpurozkhpZF3V51brTfy/KHS4ocSOB1wml0M2i4X/aeD07VJEaMD@lists.postgresql.org X-Gm-Message-State: AOJu0YySJfDt7TsfpOydYQgXBSEJO0bFsj6wODFv/8BeozST6o3xigZT jnvebxg5Nwc4XTJYQ3RrP5rs6+ZnFqTlECC5h8smgJ5Ut0Zcfa10q9Wz9x+o1HE6orh1odiRF3B adz50F+rO1pWv8a9n4GeOP50licY= X-Google-Smtp-Source: AGHT+IHRUHtwm/BVM1uU9WaiKBwT9EkViCvpvWeEoo9sY5hqhaDGfF2Xa2/joidbHXh9ju2crZkcdYKm38lfY8HW8ZU= X-Received: by 2002:a05:6902:238a:b0:e38:af38:de3c with SMTP id 3f1490d57ef6-e38cb56ec94mr2366649276.17.1732110774476; Wed, 20 Nov 2024 05:52:54 -0800 (PST) MIME-Version: 1.0 References: <3chredgnjcmccym2kczawfih226b4ac6co7p6z4jeofevrcosi@mrsxkx2x2c65> In-Reply-To: From: Pavel Stehule Date: Wed, 20 Nov 2024 14:52:16 +0100 Message-ID: Subject: Re: proposal: schema variables To: Marcos Pegoraro Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Laurenz Albe , Erik Rijkers , Michael Paquier , Amit Kapila , DUVAL REMI , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="0000000000006caccb062758774d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006caccb062758774d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi st 20. 11. 2024 v 14:29 odes=C3=ADlatel Marcos Pegoraro napsal: > Em ter., 19 de nov. de 2024 =C3=A0s 16:15, Pavel Stehule < > pavel.stehule@gmail.com> 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 O= N > 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 "o= n > 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 > --0000000000006caccb062758774d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

st 20. 11. 2024 v=C2=A014:29 odes=C3=ADlatel = Marcos Pegoraro <marcos@f10.com.br<= /a>> napsal:
=
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=C2=A0and messa= ge for what to do ON COMMIT ?

When creating a new variable you use= =C2=A0
CREATE VARIABLE ... ON COMMIT DROP | ON TRANSACTION END RESET

On PSQL=C2=A0\dV+ you show=C2=A0
Transactional end action
<= div>
Maybe all them could be just ON COMMIT
CREATE VARIABLE ... [ON= COMMIT {NO ACTION, DROP, RESET}] and \dV+ just "on commit" on ti= tle column

ON COMMI= T 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 i= mplicitly.

ON TRANSACTION END RESET can be us= ed for non temporary objects too. So this is a little bit of a different fe= ature. But the reset is executed if the transaction is ended by ROLLBACK to= o. 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 COMMI= T OR ROLLBACK, but I think TRANSACTION END is better and more intuitive, an= d 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 rol= lbacked.

Regards

Pav= el


regards
Marcos
--0000000000006caccb062758774d--