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 1sWGbN-00EAmt-B1 for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jul 2024 14:34:53 +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 1sWGbK-00EA8j-RM for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jul 2024 14:34:51 +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 1sWGbK-00EA8b-B7 for pgsql-hackers@lists.postgresql.org; Tue, 23 Jul 2024 14:34:50 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWGbI-0014UK-7k for pgsql-hackers@lists.postgresql.org; Tue, 23 Jul 2024 14:34:50 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a77e7420697so109295066b.1 for ; Tue, 23 Jul 2024 07:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1721745287; x=1722350087; 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=nTFINj/6hoWj4N3BKTNsK4/R3oz1lQvT7P0aKnqYWAs=; b=eKnSJgLbjv/eLi6mnnRXGYUTOiqqYCh8uu2rKblIcjMTb6dYXYblZReKVOSMYkOPog SPhnHgb/jag6Rn87OIp16lgDMY2zxnqNpHhi+CukPaMkYLzxTTwNT4EbEpp0Qvyp4ipu VaLjqwWHeND0PzFnYal0M93eOB4d1tTjebHkrukmALKpILUXFVS/D2njCzC8aiRpw92X xOWnOxW7J7gE7Oy6P73pS1ISmsBjt/8V3kdS71N5yQ5sxXERLwwfn+JmGe0nqcPzIPL4 02tKRZc0LOHMzpD/67hGryCN6jiTYvmKkg7iv4MIzIniEGCGtQclt4knkGLbbUnK/JDr PPxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721745287; x=1722350087; 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=nTFINj/6hoWj4N3BKTNsK4/R3oz1lQvT7P0aKnqYWAs=; b=V6tlTfiESpprlxwL9PiEg6FSXYjZXBH+hHrcatEtDiygTPPsCGur+rQ2g3v58jig/4 tkt81vmGq9336FHgRQbVDwQDKb7Uo7vR2Ttqrvo2qOxG32u1UttjqtDMw6KH2URPaey+ b3P/9zy6Axzjy0uzWL6V7n/15sWE5I2jQnEvIOOY6q34OQ4yIL0hjfu1llWdB59DIg7+ TDKQ2/vMSSVLVyw/ehlLqx1AboC/J04g42jY27Q/RToxQf7x9OEEH7N/uIh/yVGc9/WY iOKMnwa+sN8/WcFLo+QpiDnKWquhGY4CerNbrTyjEDpzaaVxcEZXIzYqYTmPnRd6Rrkn Usvg== X-Forwarded-Encrypted: i=1; AJvYcCUxo51erNvn8YlDWYWL/Qazx8gJdTyCOBDFG8/0qMx8RJhoVNYae6cMMX3h8+OYjrtODDwvaAv1yPKpXow6JZI84VkhxBD8f5hSGtP1fTwHbF+l X-Gm-Message-State: AOJu0YzWQTsiv4v9+DlobwPp84UyDNh4QUMgvmLS3NrIhv4crQ9yS9PK YXaKW9za+cftNFA0meDcLU1vwdaAEAKRtaK8d8oyF1u5qqrnhm89rYRkbTe/2gg= X-Google-Smtp-Source: AGHT+IGSE4GWjALWe2fgYWWs7wR8VSYJYZYLvJyUfCKT/X7LBTWKEKkt/WgPADvCz/jOeYY/Ddv0MA== X-Received: by 2002:a17:906:6a18:b0:a7a:8bcf:ac65 with SMTP id a640c23a62f3a-a7a8bcfacefmr233575266b.39.1721745286612; Tue, 23 Jul 2024 07:34:46 -0700 (PDT) Received: from localhost.localdomain ([88.116.133.170]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7a3c785e97sm546148666b.39.2024.07.23.07.34.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jul 2024 07:34:46 -0700 (PDT) Message-ID: <9e67d49deb18270eddb95e602c83f02b98459843.camel@cybertec.at> Subject: Re: proposal: schema variables From: Laurenz Albe To: Pavel Stehule Cc: Erik Rijkers , Michael Paquier , Zhihong Yu , Amit Kapila , DUVAL REMI , PostgreSQL Hackers Date: Tue, 23 Jul 2024 16:34:44 +0200 In-Reply-To: References: <20200924035637.GF28585@paquier.xyz> <20201001033824.GC8130@paquier.xyz> <51a9a68e8a998d04df17417d45c1dbd4@xs4all.nl> <89817942c99da01cd5e7850fe418436b@xs4all.nl> <56ca532c37eb0b540961f74a7bd5db39@xs4all.nl> <8181bd3abc647bdae5a4f78e71e62478a98c75f4.camel@cybertec.at> 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 Thanks for the fixes and the new patch set! I think that this would be a very valuable feature! This is a very incomplete review after playing with the patch set for a whi= le. Some bugs and oddities I have found: "psql" support: \? gives \dV [PATTERN] list variables I think that should say "schema variables" to distinguish them from psql variables. Running \dV when connected to an older server gives ERROR: relation "pg_catalog.pg_variable" does not exist LINE 16: FROM pg_catalog.pg_variable v ^ I think it would be better not to run the query and show a response like session variables don't exist in server version 16 The LET statement: CREATE VARIABLE testvar AS int4multirange[]; LET testvar =3D '{\{[2\,7]\,[11\,13]\}}'; ERROR: variable "laurenz.testvar" is of type int4multirange[], but exp= ression is of type text LINE 1: LET testvar =3D '{\{[2\,7]\,[11\,13]\}}'; ^ HINT: You will need to rewrite or cast the expression. Sure, I can add an explicit type cast, but I think that the type should be determined by the type of the variable. The right-hand side should be treated as "unknown", and the type input function should be used. Parameter session_variables_ambiguity_warning: --- a/src/backend/utils/misc/guc_tables.c +++ b/src/backend/utils/misc/guc_tables.c @@ -1544,6 +1544,16 @@ struct config_bool ConfigureNamesBool[] =3D false, NULL, NULL, NULL }, + { + {"session_variables_ambiguity_warning", PGC_USERSET, DEVELOPER_= OPTIONS, + gettext_noop("Raise warning when reference to a session var= iable is ambiguous."), + NULL, + GUC_NOT_IN_SAMPLE + }, + &session_variables_ambiguity_warning, + false, + NULL, NULL, NULL + }, I think the short_desc should be "Raise a warning" (with the indefinite a= rticle). DEVELOPER_OPTIONS is the wrong category. We normally use that for parame= ters that are only relevant for PostgreSQL hackers. I think it should be CLIENT_CONN_OTHER. CREATE VARIABLE command: CREATE VARIABLE str AS text NOT NULL; ERROR: session variable must have a default value, since it's declared= NOT NULL Perhaps this error message would be better: session variables declared as NOT NULL must have a default value This is buggy: CREATE VARIABLE str AS text NOT NULL DEFAULT NULL; Ugh. SELECT str; ERROR: null value is not allowed for NOT NULL session variable "lauren= z.str" DETAIL: The result of DEFAULT expression is NULL. Perhaps that is a leftover from the previous coding, but I think there ne= ed be no check upon SELECT. It should be enough to check during CREATE VARIABL= E and LET. pg_dump support: The attempt to dump a database with an older version leads to pg_dump: error: query failed: ERROR: relation "pg_catalog.pg_variable"= does not exist LINE 14: FROM pg_catalog.pg_variable v ^ Dumping variables must be conditional on the server version. IMMUTABLE variables: + + IMMUTABLE + + + The assigned value of the session variable can not be changed. + Only if the session variable doesn't have a default value, a sin= gle + initialization is allowed using the LET comma= nd. Once + done, no further change is allowed until end of transaction + if the session variable was created with clause ON TRAN= SACTION + END RESET, or until reset of all session variables by + DISCARD VARIABLES, or until reset of all sess= ion + objects by command DISCARD ALL. + + + I can see the usefulness of IMMUTABLE variables, but I am surprised that they are reset by DISCARD. What is the use case you have in mind? The use case I can envision is an application that sets a value right aft= er authentication, for use with row-level security. But then it would be ha= rmful if the user could reset the variable with DISCARD. Documentation: --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml + + The session variables can be shadowed by column references in a qu= ery. When + a query contains identifiers or qualified identifiers that could b= e used as + both a session variable identifiers and as column identifier, then= the + column identifier is preferred every time. Warnings can be emitted= when + this situation happens by enabling configuration parameter . User can ex= plicitly + qualify the source object by syntax table.column or + variable.column. + I think you mean schema.variable, not variabl= e.column. Yours, Laurenz Albe