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: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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: 2024-01-28 19:34:40
Message-ID: CAFj8pRDKRbExa8e4hw6W2BpdzDnK4_kp6JdM5iTrm=W6pdZQcw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)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?
>
> 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.
>
> * Similar with mentioning immutable session variables in plpgsql.sgml .
>
> * 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.
>
> * 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?
>

what is strange on this result?

(2024-01-28 20:32:05) postgres=# let test = 'ab';
LET
(2024-01-28 20:32:12) postgres=# let test = repeat("test", 10);
LET
(2024-01-28 20:32:19) postgres=# select test;
┌──────────────────────┐
│ test │
╞══════════════════════╡
│ abababababababababab │
└──────────────────────┘
(1 row)

(2024-01-28 20:32:21) postgres=# let test = null;
LET
(2024-01-28 20:32:48) postgres=# let test = repeat("test", 10);
LET
(2024-01-28 20:32:51) postgres=# select test;
┌──────┐
│ test │
╞══════╡
│ ∅ │
└──────┘
(1 row)

(2024-01-28 20:32:53) postgres=# select repeat(test, 10);
┌────────┐
│ repeat │
╞════════╡
│ ∅ │
└────────┘
(1 row)

"repeat" is the usual scalar function. Maybe you thought different function

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Luzanov 2024-01-28 19:51:14 Re: Things I don't like about \du's "Attributes" column
Previous Message Tomas Vondra 2024-01-28 19:11:56 Re: Add the ability to limit the amount of memory that can be allocated to backends.