Re: Schema variables - new implementation for Postgres 15

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: 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, Dmitry Dolgov <9erthalion6@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-03-30T08:49:46Z
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.

Hi

st 29. 3. 2023 v 12:17 odesílatel Peter Eisentraut <
peter.eisentraut@enterprisedb.com> napsal:

> On 24.03.23 08:04, Pavel Stehule wrote:
> > Maybe I can divide the  patch 0002-session-variables to three sections -
> > related to memory management, planning and execution?
>
> Personally, I find the existing split not helpful.  There is no value
> (to me) in putting code, documentation, and tests in three separate
> patches.  This is in fact counter-helpful (to me).  Things like the
> DISCARD command (0005) and the error messages changes (0009) can be
> separate patches, but most of the rest should probably be a single patch.
>
> I know you have been asked earlier in the thread to provide smaller
> patches, so don't change it just for me, but this is my opinion.
>

If I reorganize the patch to the following structure, can be it useful for
you?

1. really basic functionality (no temporary variables, no def expressions,
no memory cleaning)
   SELECT variable
   LET should be supported + doc, + related tests.

2. support for temporary variables (session, transaction scope),
    memory cleaning at the end of transaction

3. PL/pgSQL support
4. pg_dump
5. shadowing warning
6. ... others ...

Can it be better for you?

Regards

Pavel