Re: Schema variables - new implementation for Postgres 15

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, dean(dot)a(dot)rasheed(at)gmail(dot)com, er(at)xs4all(dot)nl, joel(at)compiler(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Schema variables - new implementation for Postgres 15
Date: 2022-10-30 18:49:41
Message-ID: CAFj8pRDatVt5rgBBa2f0jE4Cy4Rq9y_X8uXHeH9tRiZ7r0jB-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

ne 30. 10. 2022 v 19:05 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > 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?
>

It is just in category - "not implemented yet". The name, schema or owner
doesn't change behavior. It can be possible (in next versions) to change
type, default expression, immutability (I think). But the patch is long
enough so I prefer just to support basic generic ALTER related to schema,
and other possibilities to implement in next iterations.

>
> * 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.
>

yes,

This is a bug. It should be fixed

>
> * 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?
>

The behave is same like the tables

(2022-10-30 19:48:14) postgres=# \dt
Did not find any relations.
(2022-10-30 19:48:16) postgres=# \dV
Did not find any session variables.

Thank you for comments

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maciek Sakrejda 2022-10-30 23:12:33 Re: warn if GUC set to an invalid shared library
Previous Message Dmitry Dolgov 2022-10-30 18:05:42 Re: Schema variables - new implementation for Postgres 15