Re: Schema variables - new implementation for Postgres 15
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, dean.a.rasheed@gmail.com, er@xs4all.nl, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2022-10-30T18:05:42Z
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
> On Thu, Oct 13, 2022 at 07:41:32AM +0200, Pavel Stehule wrote:
> rebased with simplified code related to usage of pfree function
Thanks for the patch, great work!
I've got a couple of questions, although I haven't fully finished reviewing yet
(so more to come):
* I'm curious about ALTER VARIABLE. Current implementation allows altering only
the name, schema or the owner -- why not e.g. immutability?
* psql tab completion implementation mentions that CREATE VARIABLE could be
used inside CREATE SCHEMA:
/* CREATE VARIABLE --- is allowed inside CREATE SCHEMA, so use TailMatches */
/* Complete CREATE VARIABLE <name> with AS */
else if (TailMatches("IMMUTABLE"))
Is that correct? It doesn't like it works, and from what I see it requires
some modifications in transformCreateSchemaStmt and schema_stmt.
* psql describe mentions the following:
/*
* Most functions in this file are content to print an empty table when
* there are no matching objects. We intentionally deviate from that
* here, but only in !quiet mode, for historical reasons.
*/
I guess it's taken from listTables, and the extended versions says "because
of the possibility that the user is confused about what the two pattern
arguments mean". Are those historical reasons apply to variables as well?