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 1sUlz5-005Z8N-9U for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jul 2024 11:41:11 +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 1sUlz2-00F6gM-V7 for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jul 2024 11:41:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sUlz2-00F6gE-GL for pgsql-hackers@lists.postgresql.org; Fri, 19 Jul 2024 11:41:09 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUlyx-000NIQ-Tf for pgsql-hackers@lists.postgresql.org; Fri, 19 Jul 2024 11:41:08 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5a3b866ebc9so107005a12.3 for ; Fri, 19 Jul 2024 04:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1721389262; x=1721994062; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=nl9j+7ZifVsG6pyKu1ImztQTDS2n595EtNyOrqFFo+8=; b=ck4Jau/Ahxa9j+Dixjul8IzQEM7IYb7NzeeMoRINkHtJAUdsh6KDXodVJTRUP9SDR5 CQlVcPuY4SiGRup+G9AU/zn/Orf/cwtr+VbKLHoCvbnVQux3GiRTzDu0RuPcSITJpLdf Cts2ygmhy6urLn7aHSy3wKscwU/L4npvK3BdVcrnTs28+ri5Vi1usICmlrpXhTJIDNHz m1pXkLb0wAZDdQCGL9g59RpRkOmAbcZdZVnlagYX4TKAfHQsCi7+Cer9BYzsyRXCMUMu wXbAzkJOmimn/r4Z9I3Hq4iUAQ6SRneqY33dNmz46l3f7j+5oSYT10B2uMftxksW5Hcz eI1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721389262; x=1721994062; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nl9j+7ZifVsG6pyKu1ImztQTDS2n595EtNyOrqFFo+8=; b=qCZDk5VI3xry4IHV90dv0XNA6G6u7DNK+Q7GDlSt4TJyUXZx+UySoq9DZiuKB1GwBW x2uDo9vZGZsoLNw2CFAYNJ/rLkZE+4N1kzqX0sWvLdQrDb6/T/Jal17JRVNbOmtfj2G4 7rABpqgw05jMpiZA/l+ABy94Vxd4VxCfbHuqIB+OWkqtWOO/noXaI8J1FQigTYfpPekg Pgm55DCAiyxEDmDnqRnmsFwYiV35jGIdN05BTTq2CZMyX8lc1zxHLpCgVP23hRL9r4Bf vVAigStBCUlBl8UQd4Bv0DA6hZsY5erqaJOiC1gmwimc8f0o/INb4AVMWytwmKbOiA3h WRHQ== X-Forwarded-Encrypted: i=1; AJvYcCU/r8ciTvwIFc/zTyetQbG7xbzm0KQR7VFiCs16p5GNfx8GOPpbS/eO5yePwV+/685+ImycA1tRiECARXmElmq1NWNJ3yu/Ff5M9upL0Ey/oabN X-Gm-Message-State: AOJu0YztrG+BsVYAGqR2faTXncUOxzmlYuMBMOrM9nsBpEiVoTJNzJqx kTJBAqcDE0DC53kw7p99OrMm7iUXmP5/rJBHJQy2macXo/SVo6uo8LgnouvFuN8= X-Google-Smtp-Source: AGHT+IGoefOMR1Bo+Cn8AkvVkEMYewwMepZ+2RFFOVaBvddV7R577rXi/yJRc1wiNRCXd9t/sjIwuQ== X-Received: by 2002:a50:aa9c:0:b0:5a1:a447:9fab with SMTP id 4fb4d7f45d1cf-5a1a447a39fmr2370207a12.28.1721389261968; Fri, 19 Jul 2024 04:41:01 -0700 (PDT) Received: from localhost.localdomain ([2001:871:260:26:73ce:ac1f:9879:7ad0]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5a30c2f88a5sm1059780a12.77.2024.07.19.04.41.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jul 2024 04:41:01 -0700 (PDT) Message-ID: <8181bd3abc647bdae5a4f78e71e62478a98c75f4.camel@cybertec.at> Subject: Re: proposal: schema variables From: Laurenz Albe To: Pavel Stehule , Erik Rijkers Cc: Michael Paquier , Zhihong Yu , Amit Kapila , DUVAL REMI , PostgreSQL Hackers Date: Fri, 19 Jul 2024 13:41:00 +0200 In-Reply-To: References: <20200924035637.GF28585@paquier.xyz> <20201001033824.GC8130@paquier.xyz> <51a9a68e8a998d04df17417d45c1dbd4@xs4all.nl> <89817942c99da01cd5e7850fe418436b@xs4all.nl> <56ca532c37eb0b540961f74a7bd5db39@xs4all.nl> Autocrypt: addr=laurenz.albe@cybertec.at; prefer-encrypt=mutual; keydata=mQINBGGDwAQBEADgbWy5cKXQld3N2mF+DFyiNFbi2oBl2T+XgxpPF8wTRw2D/u4bBKXP0SYSE/lA86jIVNWWU0gf1KODIkVvgJm2w4vH2VBV1b7ddVViGl1Iu+9zaRnv9wulhnH42KefepXnoean6UT1EzLM0opF/Ik0j+40TxdRtobkBprkQUyHDXWlHc2ffPs3SipyFEP9AVLf7ejRC46CXWDnsqjOBSMEW8Z4HiK/8RrPZBsKLts8dJxKF4pygOdJb0CWk8k/X1jbcfdxo+zOLjOMvJcSJ2pFdJmQHU+JufB3rePziqQ2S9Ur6sccr9XnTC1GVBWN4Lf5VHq+vf+bFJjVwg+2hrySZnAVfcOrxoqFLErr7ug1zN2nM1kcpgA4VWn4gxlJtYNYYq+9WxX5dtvnNANlG3ZCrRKQzl8lxtzoF6Zo7LUhEqPaHDwn7Rvs+IdbOn41lF5UDTJGqmC4gS/bZydW2Fy3YWm4aSaN9fgFf8D+PVkrlKAZB7gBLz1TyHjbcRf85cYF+GKKrDld5SzMB/V60VX3oP/Eo8ikFpyWaqiz1f9X7MBot3/PjJkY+wDzp3nmb19QEcOBuQiSQ4xds2r0HewbuHTAR68u8jNNMGmpm2j4x+g09Jd/WQDjqlTBZ/jEltH41fYCCPWMfljXTOOXu2eLNGdfi7ETZogtwjM9oTtSPQARAQABtCdMYXVyZW56IEFsYmUgPGxhdXJlbnouYWxiZUBjeWJlcnRlYy5hdD6JAk4EEwEIADgWIQR0CqhbZGGABqoaSbdi8bhXA2EdmAUCYYPABAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBi8bhXA2EdmM/6EADK232JCwmBzhlj8h7U9CjG6kx0JHP3uJGv+XfsHtHAlmY/RCwF1BHMEsRlk bT5UrLvJ2jb99bA9QARzhFaxzyn0F/BUKzuIjRGNs/n6d5dNUFA0kOt8sX+TacmC GEyjEBCrVCm4ranBiUyePn9NhHNWnaex7pJyqvMLLdwW9BEMJx0Fqo+DN8ukbXmYRsmhEtd3ue+x/luYmOmJnaGtzInaY5aOJYbW9XqoRIZkZvOCgbi1FfvNmoqWa+3oVxTOgw9RafjJDyW0lTHzKGjbGI5ofMU98l+/hKJFYJqWUF6VpFJY5YIcN/1lf4ZICMwDl+MPIVo/tpq8L10seJL28nLlvw3K+cI+TVW8IW/qL/LyVoDofI3USeOORuYmhpWRhik8JXX6xf3v6GrRilJIPWNFIJbxm1ZblQiQnOw3IOW7T+8nAmPin1HKqM3VrOrJQ2VtShsefNBibNAsr1oFaqcDBkn3yGG8i6CTW+FyO4PZ+/EwNxMVgktxbYdy5AT1/lpXr5tB+phhLIyVfiBvrWs5EThxYMQ/L8Y85c3GMsAy1l/x4h3jqySIYy3SCU9+jc5UVuNnXljbvkEzJ+NLWJ6C1rACFWrMszgPdh5tCrlRY9PpmYll4JbCgb8BtxEIUmR+xr50/ZElEK5iml7Q00KUekCcDt+36PsyGFTXBzNOrkCDQRhg8AEARAAzOZ2tLHlI4rrhG411h6cdCFjBZxuljaFCxFyHn3m6wbGLqwBUWC5k8UrRqjHMz88KcTSaNO7XGAmCqPdWd2SeflPZRnNTbjsVpw7mLdffsBm4JX7kki2Pvk5h0NtYeidXT1PSpc2ri4DutYXuT9uD8RAm1wUDCE5HQNUihT/WH6opt+hskHW21uHao0+y822tG0QQcGMqdQR5Vxdxj89wiEPdqW+HpU/oOZIhrf2E7prduAppxixjHy/o1rcnoznnJvc8D3+YgI9O0LrBMij89dM55pRGbLovTR1oGR3U74sX774+0xmSzeIKwZfiMUz7Atlvfk5SHOsRUFPN2Ux9kaXiiBibQpHFxt7b lDrT4wxdLJ/XCdbPPAyl+lZtOLsaHEEZvYNyTXwZc35dVf3R4/oz20HoG6s7ct8e1 AQygj43XAERzty9SkWgxs8+grp1PrGx6FHVSYRqBM8dS/ZR6yRVwOwJXPyaSSqfIF21DkE4j1y4n+ItSewPGoRp8K/yWCikt6qlkVkO2ASNIiX04fAbtzwVOaNn8ZMRNqyvLc1fED4sr49onE4cAIcBLjcC3KL+w9DUGRQCdziROj5H2Yl/sXGPdMciUHo/Uz2rggc+2th3bQiMhrHWSsBpUkDQp0yWewemstPpPgBL3h2fHKaX8B9oH5Qu/H1IgrOuX8AEQEAAYkCNgQYAQgAIBYhBHQKqFtkYYAGqhpJt2LxuFcDYR2YBQJhg8AEAhsMAAoJEGLxuFcDYR2YuPwQAMkpGtR80pQ1gVsONhdkqj0H2eU66efP/gO3CoyaoIcvrpKYj7C2HipVSmkt1gpByL0X4AMQ/vKuknUz3wd28Ba+G1dCfbVs/Xiusq+SmpUj5rTwmYqdSjWMuCo1R6oS5hdJMdUUJYGMT0QkVlm1KnW8jkmCTl9GzjDxOAsN9O6/6lPzaGFtk9XF+34Bry/N4HKiJkqpC4+UTd0AprPfzJ2jdT64e1F0+W88X8y1bTTgNrHwK4mDiLnlE4SKRuEm54lNhJz//ar86Or5BErzNpM6TL7lk44QS06hwsMrEdKIy8J/SYJPjfzR8tIUnKscclVpOgjKaBqC+0iFiVaRqAgfOlIEiezX6kMh5Q2FIUfqs46qWhhXjRrdKOEoStYAaikdLu5ZXr7vfb0ZaDh+ZwTQtbSMFolyOkecwI81MCdbMfT/1TqIGTOdAj5as9fAakk0jb2pXgUYQ8X1DVTR8ahSDVEaw9VTmWiSvTxvguVJ1Mb7gG4Gmh6aviDTJhfXtH4rPUNXhDLqrTH8JkJjyKROOMakIF68Hjse5vUfUxreBEOtb5r1Coa2Fe7ncJayaSE7ryrDbFqpZ 36UMAx4ulWMyqJajLNGY0DdG8qIsR5nxRhrnK/mrCidZ8F9/D3bWAl4rjtHlsztN59 +AnW5l0HsQcY9ntFL/zEBOaonjdJf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, 2021-04-10 at 08:58 +0200, Pavel Stehule wrote: > I am sending a strongly updated patch for schema variables. >=20 > I rewrote an execution of a LET statement. In the previous implementation= I hacked > STMT_SELECT. Now, I introduced a new statement STMT_LET, and I implemente= d a new > executor node SetVariable. Now I think this implementation is much cleane= r. > Implementation with own executor node reduces necessary work on PL side -= and allows > the LET statement to be prepared - what is important from a security view= . >=20 > I'll try to write a second implementation based on a cleaner implementati= on like > utility command too. I expect so this version will be more simple, but ut= ility > commands cannot be prepared, and probably, there should be special suppor= t for > any PL. I hope a cleaner implementation can help to move this patch. >=20 > We can choose one variant in the next step and this variant can be finali= zed. >=20 > Notes, comments? Thank you! I tried to give the patch a spin, but it doesn't apply any more, and there are too many conflicts for me to fix manually. So I had a look at the documentation: > --- a/doc/src/sgml/advanced.sgml > +++ b/doc/src/sgml/advanced.sgml > + > + The value of a schema variable is local to the current session. Retr= ieving > + a variable's value returns either a NULL or a default value, unless = its value > + is set to something else in the current session with a LET command. = The content > + of a variable is not transactional. This is the same as in regular v= ariables > + in PL languages. > + > + > + > + Schema variables are retrieved by the SELECT SQL = command. > + Their value is set with the LET SQL command. > + While schema variables share properties with tables, their value can= not be updated > + with an UPDATE command. "PL languages" -> "procedural languages". Perhaps a link to the "procedura= l Languages" chapter would be a good idea. I don't think we should say "regular" variables: are there irregular variab= les? My feeling is that "SQL statement XY" is better than "XY SQL command". I think the last sentence should go. The properties they share with tables= are that they live in a schema and can be used with SELECT. Also, it is not necessary to mention that they cannot be UPDATEd. They can= not be TRUNCATEd or CALLed either, so why mention UPDATE specifically? > --- a/doc/src/sgml/catalogs.sgml > +++ b/doc/src/sgml/catalogs.sgml > + > + varisnotnull > + boolean > + > + > + True if the schema variable doesn't allow null value. The default= value is false. > + > + I think the attribute should be called "varnotnull", similar to "attnotnull= ". This attribute determines whether the variable is NOT NULL or not, not abou= t its current setting. There is a plural missing: "doesn't allow null valueS". > + > + vareoxaction > + char > + > + > + n =3D no action, d =3D drop= the variable, > + r =3D reset the variable to its default value. > + > + Perhaps the name "varxactendaction" would be better. A descriptive sentence is missing. > --- /dev/null > +++ b/doc/src/sgml/ref/create_variable.sgml > + > + The value of a schema variable is local to the current session. Retri= eving > + a variable's value returns either a NULL or a default value, unless i= ts value > + is set to something else in the current session with a LET command. T= he content > + of a variable is not transactional. This is the same as in regular va= riables in PL languages. > + "regular variables in PL languages" -> "variables in procedural languages" > + > + Schema variables are retrieved by the SELECT SQL c= ommand. > + Their value is set with the LET SQL command. > + While schema variables share properties with tables, their value cann= ot be updated > + with an UPDATE command. > + That's just a literal copy from the tutorial section. I have the same comm= ents as there. > + > + NOT NULL > + > + > + The NOT NULL clause forbids to set the variable= to > + a null value. A variable created as NOT NULL and without an explic= itly > + declared default value cannot be read until it is initialized by a= LET > + command. This obliges the user to explicitly initialize the variab= le > + content before reading it. > + > + > + What is the reason for that behavior? I'd have expected that a NOT NULL variable needs a default value. > --- /dev/null > +++ b/doc/src/sgml/ref/let.sgml > + > + sql_expression > + > + > + An SQL expression. The result is cast into the schema variable's t= ype. > + > + > + Always, even if there is no assignment or implicit cast? I see no such wording fir INSERT or UPDATE, so if only assignment casts are= used, the second sentence should be removed. > --- a/doc/src/sgml/ref/pg_restore.sgml > +++ b/doc/src/sgml/ref/pg_restore.sgml > + > + > + > + > + > + Restore a named schema variable only. Multiple schema variables= may be specified with > + multiple switches. > + > + > + Do we need that? We have no such option for functions and other non-relati= ons. And if we really want such an option for "pg_restore", why not for "pg_dump= "? Yours, Laurenz Albe