Re: Schema variables - new implementation for Postgres 15
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Sergey Shinderuk <s.shinderuk@postgrespro.ru>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, Julien Rouhaud <rjuju123@gmail.com>, dean.a.rasheed@gmail.com, er@xs4all.nl, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2023-11-18T13:25:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow underscores in integer and numeric constants.
- faff8f8e47f1 16.0 cited
-
Remove special outfuncs/readfuncs handling of RangeVar.catalogname.
- 3cece34be842 16.0 cited
-
Remove extra space from dumped ALTER DEFAULT PRIVILEGES.
- 2af33369e794 16.0 cited
-
Create FKs properly when attaching table as partition
- b0284bfb1db5 16.0 cited
-
psql: improve tab-complete's handling of variant SQL names.
- 02b8048ba5dc 15.0 cited
so 18. 11. 2023 v 14:19 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal: > Hi > > pá 17. 11. 2023 v 20:17 odesílatel Dmitry Dolgov <9erthalion6@gmail.com> > napsal: > >> > On Wed, Aug 23, 2023 at 04:02:44PM +0200, Pavel Stehule wrote: >> > NameListToString is already buildin function. Do you think >> NamesFromList? >> > >> > This is my oversight - there is just `+extern List *NamesFromList(List >> > *names); ` line, but sure - it should be in 0002 patch >> > >> > fixed now >> >> Right, thanks for fixing. >> >> I think there is a wrinkle with pg_session_variables function. It >> returns nothing if sessionvars hash table is empty, which has two >> consequences: >> >> * One might get confused about whether a variable is created, >> based on the information from the function. An expected behaviour, but >> could be considered a bad UX. >> >> =# CREATE VARIABLE var1 AS varchar; >> >> -- empty, is expected >> =# SELECT name, typname, can_select, can_update FROM >> pg_session_variables(); >> name | typname | can_select | can_update >> ------+---------+------------+------------ >> (0 rows) >> >> -- but one can't create a variable >> =# CREATE VARIABLE var1 AS varchar; >> ERROR: 42710: session variable "var1" already exists >> LOCATION: create_variable, pg_variable.c:102 >> >> -- yet, suddenly after a select... >> =# SELECT var2; >> var2 >> ------ >> NULL >> (1 row) >> >> -- ... it's not empty >> =# SELECT name, typname, can_select, can_update FROM pg_sessio >> n_variables(); >> name | typname | can_select | can_update >> ------+-------------------+------------+------------ >> var2 | character varying | t | t >> (1 row) >> >> * Running a parallel query will end up returning an empty result even >> after accessing the variable. >> >> -- debug_parallel_query = 1 all the time >> =# CREATE VARIABLE var2 AS varchar; >> >> -- empty, is expected >> =# SELECT name, typname, can_select, can_update FROM >> pg_session_variables(); >> name | typname | can_select | can_update >> ------+---------+------------+------------ >> (0 rows) >> >> -- but this time an access... >> SELECT var2; >> var2 >> ------ >> NULL >> (1 row) >> >> -- or set... >> =# LET var2 = 'test'; >> >> -- doesn't change the result, it's still empty >> =# SELECT name, typname, can_select, can_update FROM >> pg_session_variables(); >> name | typname | can_select | can_update >> ------+---------+------------+------------ >> (0 rows) >> >> Would it be a problem to make pg_session_variables inspect the catalog >> or something similar if needed? >> > > It can be very easy to build pg_session_variables based on iteration over > the system catalog. But I am not sure if we want it. pg_session_variables() > is designed to show the variables from session memory, and it is used for > testing. Originally it was named pg_debug_session_variables. If we iterate > over catalog, it means using locks, and it can have an impact on isolation > tests. > > So maybe we can introduce a parameter for this function to show all > session variables (based on catalog) or only used based on iteration over > memory. Default can be "all". What do you think about it? > > The difference between debug_parallel_query = 1 and debug_parallel_query = > 0 is strange - and I'll check it. > looks so pg_session_variables() doesn't work in debug_paralel_query mode.