Horton

Re: Schema variables - new implementation for Postgres 15

Pavel Stehule <pavel.stehule@gmail.com>

View thread
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: 2024-01-29T07:57: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 →

  1. Allow underscores in integer and numeric constants.

  2. Remove special outfuncs/readfuncs handling of RangeVar.catalogname.

  3. Remove extra space from dumped ALTER DEFAULT PRIVILEGES.

  4. Create FKs properly when attaching table as partition

  5. psql: improve tab-complete's handling of variant SQL names.

Attachments

Hi

ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthalion6@gmail.com>
napsal:

> Thanks for the update, smaller patches looks promising.
>
> Off the list Pavel has mentioned that the first two patches contain a
> bare minimum for session variables, so I've reviewed them once more and
> suggest to concentrate on them first. I'm afraid the memory cleanup
> patch has to be added to the "bare minimum" set as well -- otherwise in
> my tests it was too easy to run out of memory via creating, assigning
> and dropping variables. Unfortunately one can't extract those three
> patches from the series and apply only them, the memory patch would have
> some conflicts. Can you maybe reshuffle the series to have those patches
> (1, 2 + 8) as first three?
>

probably you need too

0006-function-pg_session_variables-for-cleaning-tests.patch and
0007-DISCARD-VARIABLES.patch

6 is necessary for testing of cleaning


> If that's possible, my proposal would be to proceed with them first. To the
> best of my knowledge they look good to me, except few minor details:
>
> * The documentation says in a couple of places (ddl.sgml,
>   create_variable.sgml) that "Retrieving a session variable's value
>   returns either a NULL or a default value", but as far as I see the
>   default value feature is not implemented within first two patches.
>

should be fixed


>
> * Similar with mentioning immutable session variables in plpgsql.sgml .
>

fixed


>
> * Commentary to LookupVariable mentions a rowtype_only argument:
>
>         +/*
>         + * Returns oid of session variable specified by possibly
> qualified identifier.
>         + *
>         + * If not found, returns InvalidOid if missing_ok, else throws
> error.
>         + * When rowtype_only argument is true the session variables of not
>         + * composite types are ignored. This should to reduce possible
> collisions.
>         + */
>         +Oid
>         +LookupVariable(const char *nspname,
>         +                          const char *varname,
>         +                          bool missing_ok)
>
>   but the function doesn't have it.
>

removed

Regards

Pavel



>
> * I've noticed an interesting result when a LET statement is used to
> assign a
>   value without a subquery:
>
>         create variable test as text;
>         -- returns NULL
>         select test;
>
>         -- use repeat directly without a subquery
>         let test = repeat("test", 100000);
>
>         -- returns NULL
>         select test;
>
>   I was expecting to see an error here, is this a correct behaviour?
>