Thanks for the quick response. It’s 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’t if there is no chance of it being accepted. Are we totally opposed? > On Sep 2, 2022, at 15:16 , Tom Lane <t...@sss.pgh.pa.us> wrote: > > PG Doc comments form <nore...@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/
