Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oUF9M-0006lv-8D for pgsql-docs@arkaria.postgresql.org; Fri, 02 Sep 2022 22:28:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oUF9K-00060D-Uh for pgsql-docs@arkaria.postgresql.org; Fri, 02 Sep 2022 22:28:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oUF9K-000603-Il for pgsql-docs@lists.postgresql.org; Fri, 02 Sep 2022 22:28:30 +0000 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oUF9I-0007IR-2R for pgsql-docs@lists.postgresql.org; Fri, 02 Sep 2022 22:28:29 +0000 Received: by mail-pf1-x42e.google.com with SMTP id w139so3182294pfc.13 for ; Fri, 02 Sep 2022 15:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:cc:date:in-reply-to:subject:mime-version :from:from:to:cc:subject:date; bh=z1QnPTw5VnGKjkeZKjtW0Dj3aC84rdfEv6Nmv+clQFY=; b=RPtGGkB+ELjDsCYC4OJEMdgZz9L3uVyYNSKn3aVe+d+C/hz0YZEBuf8uMtDkjbPaH/ D0wqFd20lh3ws6wFwgHzPSLYor2N/T+S6Ee2hSFZFV2CV/cXV9bjYPP+RBniY3fHyXT3 /mD0UfdS1ZXuAqpnAjCp9sXv/wGE5JnWgRNlyaR4riPwhW3Z6rEIxvOQsNDaBiT3Ybal /OIwSKUO/c4jnXRUmgY1yIitV+86zhNIPsbjaAwiFcF2ZDk5eyaSmS+0n8LnIP1efCf0 ByNklIku3jLr3g3kwZsLZfKzJcSg7zmU//wUseoqhakq+0Fz6Zq5bfhK1L9Sf/NCdpXI zCHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:cc:date:in-reply-to:subject:mime-version :from:x-gm-message-state:from:to:cc:subject:date; bh=z1QnPTw5VnGKjkeZKjtW0Dj3aC84rdfEv6Nmv+clQFY=; b=uDuKO4HHvOswwKQ9/Yt713TbOhnoTNw5Bhg07bvFYoBJEDWmB87WuAr/Ga+1DzLTdh eFrwOgy/OwVNe1cSRaQioLac3ndzYY0j7qEEPM644hGk6fn+MCYxeNk4u8p3HtZu8mSD Z5spzXW9+Y0PNMVjv35q5tRmeUvkBZvc4eJ928JfoFiiGqQu5MdVpaStXAUJtTf3+5Li x4oNpl5NTar270x2NW065PdZRFYdhy8GTu084Q0oGYiZ8o+gYlZacFpVtfaoLErYR88D 8X1mNLSAZ1ZkenyCa7wldFNttFWMRytHcouSwolgbiW2X8/NFDiP8lHL7UMTKTCZWx8n zVoA== X-Gm-Message-State: ACgBeo2hfk0K+FQ+uQfTNvQVG4gtkb4FukJrZj+nwbcquGFvw/TvOgjs ek/1oexafcTPb9e+Lnns1fzMKQx956j/3g== X-Google-Smtp-Source: AA6agR5Qnbe3nJWz1w8jbL6YdP+wumlDYe6lFAE+QoUwr/oHQWoZcG5OeTds3FpWaaz5pPT7Tsln1Q== X-Received: by 2002:a65:6b8e:0:b0:42a:162c:e3a0 with SMTP id d14-20020a656b8e000000b0042a162ce3a0mr32426694pgw.464.1662157704235; Fri, 02 Sep 2022 15:28:24 -0700 (PDT) Received: from smtpclient.apple ([2600:8801:8800:29::1b]) by smtp.gmail.com with ESMTPSA id d22-20020a656b96000000b0041c35462316sm1917219pgw.26.2022.09.02.15.28.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Sep 2022 15:28:23 -0700 (PDT) From: "guyren@relevantlogic.com" X-Google-Original-From: "guyren@relevantlogic.com" Content-Type: multipart/alternative; boundary="Apple-Mail=_8C19FACD-3F7B-4ACA-AA71-6700E11BB71D" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: No discussion of custom variables; no "See also" for set_config, current_setting, pg_settings In-Reply-To: <1228416.1662156969@sss.pgh.pa.us> Date: Fri, 2 Sep 2022 15:28:19 -0700 Cc: pgsql-docs@lists.postgresql.org X-Mailbutler-Message-Id: F2C8434E-2EB0-45BE-BA55-8D0F8CB66F36 Message-Id: References: <166215027042.1235918.13727650130980574270@wrigleys.postgresql.org> <1228416.1662156969@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3696.120.41.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_8C19FACD-3F7B-4ACA-AA71-6700E11BB71D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the quick response. It=E2=80=99s a clearly useful, simplifying feature. Unless it is likely = to be removed at some point, I propose it should be documented and = declared supported wherever relevant. In any event, I am happy to prepare some documentation changes that = mention these caveats, but I won=E2=80=99t if there is no chance of it = being accepted. Are we totally opposed? > On Sep 2, 2022, at 15:16 , Tom Lane wrote: >=20 > PG Doc comments form writes: >> A reader of this section >> https://www.postgresql.org/docs/current/sql-set.html of the = documentation >> might be forgiven for thinking that Postgres does not support custom >> variables. >=20 > They are, in fact, *not* a supported feature. The only intended use > of non-core GUCs was for extensions' parameters. People have abused = the > mechanism to create ad-hoc session variables, but we don't encourage = it. > The underlying code won't scale to large numbers of variables, there's > no way to declare properties of such a variable in SQL, etc. >=20 > There's been an ongoing effort to create a respectable substitute, > but it still hasn't gotten across the finish line [1]. >=20 > regards, tom lane >=20 > [1] https://commitfest.postgresql.org/39/1608/ --Apple-Mail=_8C19FACD-3F7B-4ACA-AA71-6700E11BB71D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the quick response.

It=E2=80=99s a clearly useful, = simplifying feature. Unless it is likely to be removed at some point, I = propose it should be documented and declared supported wherever = relevant.

In = any event, I am happy to prepare some documentation changes that mention = these caveats, but I won=E2=80=99t if there is no chance of it being = accepted. Are we totally opposed?

On Sep = 2, 2022, at 15:16 , Tom Lane <tgl@sss.pgh.pa.us> wrote:

PG = Doc comments form <noreply@postgresql.org> writes:
A reader of this = section
https://www.postgresql.org/docs/current/sql-set.html of = the documentation
might be forgiven for thinking that = Postgres does not support custom
variables.

They are, in fact, *not* a = supported feature.  The only intended use
of non-core = GUCs was for extensions' parameters.  People have abused the
mechanism to create ad-hoc session variables, but we don't = encourage it.
The underlying code won't scale to large = numbers of variables, there's
no way to declare properties = of such a variable in SQL, etc.

There's = been an ongoing effort to create a respectable substitute,
but it still hasn't gotten across the finish line [1].

regards, tom lane
[1] https://commitfest.postgresql.org/39/1608/

3D""= --Apple-Mail=_8C19FACD-3F7B-4ACA-AA71-6700E11BB71D--