Re: Re: proposal: schema variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Erik Rijkers <er(at)xs4all(dot)nl>, Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, DUVAL REMI <REMI(dot)DUVAL(at)cheops(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Re: proposal: schema variables
Date: 2025-01-03 22:59:30
Message-ID: CAFj8pRAVoWzkx8Y3or-frYwszyLSjxzs9jYTm3rx00qN+21ZHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Hi

pá 3. 1. 2025 v 8:18 odesílatel jian he <jian(dot)universality(at)gmail(dot)com>
napsal:

> hi.
>
> in the function svariableStartupReceiver all these "ereport(ERROR"
> cannot happen,
> since transformLetStmt already did all the heavy work.
> base on
> https://www.postgresql.org/docs/current/error-message-reporting.html
> all these "ereport(ERROR," in the svariableStartupReceiver can be
> simplified as "elog(ERROR,"
> or Assert.
>
>
> After standard_ExecutorStart->InitPlan, queryDesc.tupDesc will not
> include attr->attisdropped is true scarenio.
> In standard_ExecutorStart, I added the following code then ran the
> regress test again to prove my point.
>
> standard_ExecutorStart
> /*
> * Initialize the plan state tree
> */
> InitPlan(queryDesc, eflags);
> for (int i = 0; i < queryDesc->tupDesc->natts; i++)
> {
> Form_pg_attribute attr = TupleDescAttr(queryDesc->tupDesc, i);
> if (attr->attisdropped)
> {
> elog(INFO, "some attribute is dropped queryDesc->operation
> is %d", queryDesc->operation);
> }
> }
> MemoryContextSwitchTo(oldcontext);
> -------------------------
> svariableStartupReceiver parameter typeinfo is from queryDesc->tupDesc
> So I think svariableStartupReceiver, typeinfo->natts will always equal one.
> therefore SVariableState.slot_offset is not necessary.
>

It is true. The syntax allows just `expression` or `(subquery)`, and all
dirty work does execution of subquery

>
> overall, i think svariableStartupReceiver can be simplified as the
> following:
>
> static void
> svariableStartupReceiver(DestReceiver *self, int operation, TupleDesc
> typeinfo)
> {
> SVariableState *myState = (SVariableState *) self;
> int natts = typeinfo->natts;
> Form_pg_attribute attr;
> LOCKTAG locktag PG_USED_FOR_ASSERTS_ONLY;
> Assert(myState->pub.mydest == DestVariable);
> Assert(OidIsValid(myState->varid));
> Assert(SearchSysCacheExists1(VARIABLEOID, myState->varid));
> #ifdef USE_ASSERT_CHECKING
> SET_LOCKTAG_OBJECT(locktag,
> MyDatabaseId,
> VariableRelationId,
> myState->varid,
> 0);
> Assert(LockHeldByMe(&locktag, AccessShareLock, false));
> #endif
> Assert(natts == 1);
> attr = TupleDescAttr(typeinfo, 0);
> myState->need_detoast = attr->attlen == -1;
> myState->rows = 0;
> }
>

done + regress tests

>
> I've attached the file containing the changes I mentioned earlier.
>
> -------------------------<<>>>-------------------------------
> Overall, 0001 and 0002 the doc looks good to me now.
> The following are only some minor issues I came up with.
>
> In Table 5.1. ACL Privilege Abbreviations
> <table id="privilege-abbrevs-table">
> <title><acronym>ACL</acronym> Privilege Abbreviations</title>
>
> <literal>VARIABLE</literal> (occurred 3 times)
> should be
> <literal>SESSION VARIABLE</literal>
> ?
>

changed

>
> doc/src/sgml/glossary.sgml
> I want to do minor tweak. from
> <para>
> A persistent database object that holds a value in session memory.
> This
> value is private to each session and is released when the session
> ends.
> Read or write access to session variables is controlled by privileges,
> similar to other database objects.
> </para>
> to
> <para>
> A persistent database object that holds a value in session memory.
> This
> value is private to each session and is reset to default value
> (null) when the session ends.
> Read or write access to session variables is controlled by access
> privileges,
> similar to other database objects.
> </para>
>

I think the sentence "and is reset to default value (null) when the
session ends" is a little bit misguided. The memory is
really released. I changed it to

A persistent database object that holds a value in session memory.
This
value is private to each session and is released when the session ends.
The default value of the session variable is null. Read or write
access
to session variables is controlled by privileges, similar to other
database
objects.

> in let.sgml.
> <para>
> Example:
> <programlisting>
> CREATE VARIABLE myvar AS integer;
> LET myvar = 10;
> LET myvar = (SELECT sum(val) FROM tab);
> </programlisting>
> </para>
>
> it should be
> <refsect1>
> <title>Examples</title>
> ...your example code
> </refsect1>
>

done

Regards

Pavel

Attachment Content-Type Size
v20250103-0022-pg_restore-A-variable.patch text/x-patch 2.8 KB
v20250103-0020-this-patch-changes-error-message-column-doesn-t-exis.patch text/x-patch 29.2 KB
v20250103-0019-expression-with-session-variables-can-be-inlined.patch text/x-patch 4.2 KB
v20250103-0021-transactional-variables.patch text/x-patch 37.3 KB
v20250103-0018-plpgsql-implementation-for-LET-statement.patch text/x-patch 17.2 KB
v20250103-0017-allow-parallel-execution-queries-with-session-variab.patch text/x-patch 11.9 KB
v20250103-0016-allow-read-an-value-of-session-variable-directly-fro.patch text/x-patch 15.5 KB
v20250103-0015-Implementation-of-NOT-NULL-and-IMMUTABLE-clauses.patch text/x-patch 33.9 KB
v20250103-0014-Implementation-of-DEFAULT-clause-default-expressions.patch text/x-patch 32.1 KB
v20250103-0013-Implementation-ON-TRANSACTION-END-RESET-clause.patch text/x-patch 14.6 KB
v20250103-0012-implementation-of-temporary-session-variables.patch text/x-patch 40.6 KB
v20250103-0011-PREPARE-LET-support.patch text/x-patch 7.4 KB
v20250103-0010-EXPLAIN-LET-support.patch text/x-patch 8.2 KB
v20250103-0009-dynamic-check-of-usage-of-session-variable-fences.patch text/x-patch 16.2 KB
v20250103-0008-variable-fence-syntax-support-and-variable-fence-usa.patch text/x-patch 19.4 KB
v20250103-0007-GUC-session_variables_ambiguity_warning.patch text/x-patch 15.1 KB
v20250103-0006-plpgsql-tests.patch text/x-patch 16.9 KB
v20250103-0005-memory-cleaning-after-DROP-VARIABLE.patch text/x-patch 21.0 KB
v20250103-0004-DISCARD-VARIABLES.patch text/x-patch 9.6 KB
v20250103-0003-function-pg_session_variables-for-cleaning-tests.patch text/x-patch 4.3 KB
v20250103-0002-Storage-for-session-variables-and-SQL-interface.patch text/x-patch 158.5 KB
v20250103-0001-Enhancing-catalog-for-support-session-variables-and-.patch text/x-patch 167.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-01-03 23:38:28 Re: Parallel heap vacuum
Previous Message Gurjeet Singh 2025-01-03 22:55:04 Re: Proposal: add new API to stringinfo

Browse pgsql-performance by date

  From Date Subject
Next Message Pavel Stehule 2025-01-04 05:36:56 Re: Re: proposal: schema variables
Previous Message jian he 2025-01-03 07:18:22 Re: Re: proposal: schema variables