Horton

Re: proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>, Zhihong Yu <zyu@yugabyte.com>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-25T16:32:24Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

Attachments

Hi

čt 25. 7. 2024 v 15:52 odesílatel Laurenz Albe <laurenz.albe@cybertec.at>
napsal:

> Thanks for the updated patch set.
>
> I found a problem in 0019-transactional-variables.patch:
>
> --- a/doc/src/sgml/catalogs.sgml
> +++ b/doc/src/sgml/catalogs.sgml
> @@ -9851,6 +9851,17 @@ SCRAM-SHA-256$<replaceable>&lt;iteration
> count&gt;</replaceable>:<replaceable>&l
>        </para></entry>
>       </row>
>
> +     <row>
> +      <entry><structfield>varistransact</structfield></entry>
> +      <entry><type>boolean</type></entry>
> +      <entry></entry>
> +      <entry>
> +       True, when the variable is "transactional". In case of transaction
> +       rollback, transactional variables are reset to their content at the
> +       transaction start. The default value is false.
> +      </entry>
> +     </row>
>
> That's messed up; it should be
>
>      <row>
>       <entry role="catalog_table_entry"><para role="column_definition">
>        <structfield>varistransact</structfield> <type>boolean</type>
>       </para>
>       <para>
>        True, when the variable is <quote>transactional</quote>. In the case
>        of a transaction rollback, transactional variables are reset to the
>        value they had when the transaction started. The default value is
>        <literal>false</literal>.
>       </para></entry>
>      </row>
>
>
changed


> I have started reading through the first patch, and so far I have only
> found
> language problems.
>
> I wonder how I should go about this.  At first, I intended to send an
> edited
> version of the first patch, but as later patches depend on earlier patches,
> that would mess up the patch set.
>
> I can send my suggested modifications in text, but then you have to copy
> and
> paste them all, which is cumbersome.
>
> What would be best for you?
>

send me it in any form - probably the diff of patches are best. I'll do
necessary fixes.

There are not good tool for maintaining chronologically incremental
patchset


>
> Thinking further, I wondered about the order of patches.
> If some committer eventually takes mercy on this patch set, I expect that
> only a part of the functionality will go in as a first step.
> Does the order of the patches in the patch set match such a process?
>

yes

we talk so first seven patches are mandatory - others are optional and
introduce new functionality or increase performance



>
> I'd guess that temporary session variables or ON TRANSACTION END RESET
> would be things that can be committed later on, but PL/pgSQL support
> should be in the first commit.
>

The plpgsql is supported by a second patch, because variables are
accessible by queries. But patch 16 introduces the
PLpgSQL LET command, and then allows us to evaluate an expression as a
simple expression, which is significantly faster.


> What is your approach to that?
>

The first six, seven patches are fundamental.  For others we can talk about
priorities. I see performance related patches to be more important, but
they are a little bit more technically difficult or maybe related to a not
too cool area now (like PL/pgSQL - I like it, but almost all people's
stored procedures aren't used). Implementation of new features is almost
done by simple patches. And again for somebody temp variables are not
important (usage temp variables in PLpgSQL is +/- zero), but for others can
be very important (it can be very interesting for writing psql scripts,
because it allows parametrization of DO commands, and it is cheaper than
temp tables for passing result).

So others patches have some order, because there has to be some order, but
it is not final or immutable. I can imagine throwing these patches to
different patchset. On the second hand, the size of these patches is less
than the first two, and I think it is interesting, because from my
perspective, these patches cover this area completely. But again, the order
of these patches is important for some dependencies in files (regress
tests), but it doesn't draw the priority of implemented features. Current
state is the result of my work or work of other peoples that did review of
these patches. I am open to changing this order, if somebody would do it.

Regards

Pavel



> Yours,
> Laurenz Albe
>