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 1tDm9h-0036av-K2 for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 14:58:09 +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 1tDm9g-006WPH-Aj for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 14:58:08 +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 1tDm9f-006WP7-Sw for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 14:58:08 +0000 Received: from mail-yw1-x112e.google.com ([2607:f8b0:4864:20::112e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDm9b-002tWC-MY for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 14:58:05 +0000 Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-6eeb31b10ceso19859177b3.1 for ; Wed, 20 Nov 2024 06:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732114683; x=1732719483; 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=Gvx1cJbH6c7YIAa2AIyCvQhu/rpucGGOaoAP9l6C3aU=; b=h4R/tLes0ow9m30RatAs1Xak866zuGMVGjcyeQm1ThqVkV4NJJwDuBqMZxG8KmXR/W JKDz/5mgyEzDB2WmeglCLSe2WcQfiOflqy7oFaotyEYQqFSvYu2/pEEeSu1L4EdGX4Hp J6jeiviIJs98byX48AaTQcWmljKoVMhr/ROeGpb21Xbnzbe4oQL3YryddF/THEU8YDQn 1V6V2hwEaYVt7Y9sPCYFL8nFiNOqjwXORc0nwlFWApG+KgOVFeUxodLYHTw9T+JNCj07 5hpbQS/PZCLhLOf8wESZ3y694Za5JI0O/ui9Ga8Jqg1CkgrmBEX9C0vjn9OdSg5I3Tly UpRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732114683; x=1732719483; 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=Gvx1cJbH6c7YIAa2AIyCvQhu/rpucGGOaoAP9l6C3aU=; b=n59dKV3UvTGcePHNc/jEm1dT8aoZa/tpRh9EPvCgrjdjeT112qV35rVbqIel7ZQqw5 bcxD2dfkmMPxgIO67HVyfaGbiFo90QuMjIV1oWugmjxuuRNkAMaLu5Tuhr62ZZldwtdq McybKL7iUE46mq5JMlhcoSeH6j7IZ3yWStv/axjYeoCSWQkJu7XKjHuOieR+Ltx4JEkk v9p+laETwQULa5K4p17MyorqRdoGCo25BCeQrnRS/vVf1V8w3bBo386Q7HrWKuov1dtD FvmpHi75x+Q6+2E5yBjVeWCm10Kc3XsmNKVUOrIJ+YbBGjiECunrI2xVv0fcM7PMfkZj D+Fg== X-Forwarded-Encrypted: i=1; AJvYcCWJXoxSMGvia5YdBRycx8c+2cc/t8LSzX8i6iK5bCDNvAtKa2QOvXp/pup6wenndUj33whOHqvY6p8ckP+k@lists.postgresql.org X-Gm-Message-State: AOJu0YzStT+GJxs+/mnNvTXDMeA7KDwA4iGKE8AXgV0f5gscUNiNcAo9 Dj+vNKSDzXFtX5COgHKrngncBDkgPzf+bFB5tpTcjZyR8bVPXnZ/gpb5iulKylGZ4q3XBm7ESFk BGvPNut/7CM1Gzq8kYWG9lu6ZiTc= X-Google-Smtp-Source: AGHT+IFo0R7OxebS5sXht8Omf2hPmvKHfYTb12K6RA5SM1Ym4hENfj+KchzwJr7wphhXX1H0rIuZ0b6OwClWKddt3TE= X-Received: by 2002:a05:690c:6485:b0:6e5:cb46:4641 with SMTP id 00721157ae682-6eebd0dcb00mr34161077b3.13.1732114682969; Wed, 20 Nov 2024 06:58:02 -0800 (PST) MIME-Version: 1.0 References: <3chredgnjcmccym2kczawfih226b4ac6co7p6z4jeofevrcosi@mrsxkx2x2c65> In-Reply-To: From: Pavel Stehule Date: Wed, 20 Nov 2024 15:57:23 +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="0000000000006386f3062759602a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006386f3062759602a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable st 20. 11. 2024 v 15:15 odes=C3=ADlatel Marcos Pegoraro napsal: > Em qua., 20 de nov. de 2024 =C3=A0s 10:52, Pavel Stehule < > pavel.stehule@gmail.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 t= he > end of transaction, independently if commited or rolled back > I feel it differently - when I read ON COMMIT, then I expect really just a COMMIT event, not ROLLBACK. Attention - the metadata about variables are transactional, but the variables are not transactional (by default). But this feeling can be subjective. The objective argument against using ON COMMIT like ON TRANSACTION END is fact, so we lost a possibility for a more precious setting. I can imagine scenarios with ON COMMIT RESET - and variable can hold some last value from transaction, or ON ROLLBACK RESET - and variable can hold some computed value from successfully ended transaction - last inserted id. In this case, I don't see a problem to reopen a discussion about syntax or postpone this feature. I think the possibility to reset variables at some specified time can be an interesting feature (that can increase safety, because the application doesn't need to solve initial setup), but from the list of implemented features for session variables, this is not too far from the end. If TRANSACTION END is not intuitive - with exactly the same functionality can be RESET AT TRANSACTION START - so the ON TRANSACTION END can be transformed to ON BEGIN RESET, and this syntax can be maybe better, because it signalize, for every transaction, the variable will be initialized to default. What do you think? Can be ON BEGIN RESET acceptable for you. Regards Pavel --0000000000006386f3062759602a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


st 20. 11. 2024 v=C2= =A015:15 odes=C3=ADlatel Marcos Pegoraro <marcos@f10.com.br> napsal:
Em qua., 20 de nov. de 2024 =C3=A0s 10:52, Pavel Stehule <pavel.stehule@gmail.c= om> escreveu:
COMMIT can be a lit= tle 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 t= he same at the end of transaction, independently if commited or rolled back=

I feel it differently - = when I read ON COMMIT, then I expect really just a COMMIT event, not ROLLBA= CK.=C2=A0 Attention - the metadata about variables are transactional, but t= he variables are not transactional (by default).

<= div>But this feeling can be subjective. The objective argument against usin= g ON COMMIT like ON TRANSACTION END is fact, so we lost a possibility for a= more precious setting.

I can imagine scenari= os with ON COMMIT RESET - and variable can hold some last value from transa= ction, or ON ROLLBACK RESET - and variable can hold some computed value fro= m successfully ended transaction - last inserted id.

In this case, I don't see a problem to reopen a discussion abou= t syntax or postpone this feature. I think the possibility to reset variabl= es at some specified time can be an interesting feature (that can increase = safety, because the application doesn't need to solve initial setup),= =C2=A0 but from the list of implemented features for session variables, thi= s is not too far from the end. If TRANSACTION END is not intuitive - with e= xactly the same functionality can be RESET AT TRANSACTION START - so the ON= TRANSACTION END can be transformed to ON BEGIN RESET, and this syntax can = be maybe better, because it signalize, for every transaction, the variable = will be initialized to default. What do you think? Can be ON BEGIN RESET ac= ceptable for you.

Regards

=
Pavel





--0000000000006386f3062759602a--