Horton

Re: proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Marcos Pegoraro <marcos@f10.com.br>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-11-20T14:57:23Z
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.

st 20. 11. 2024 v 15:15 odesílatel Marcos Pegoraro <marcos@f10.com.br>
napsal:

> Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule <
> pavel.stehule@gmail.com> escreveu:
>
>> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
>> think.
>>
>>>
> Exactly to be not messy I would just ON COMMIT for all, and DOCs can
> explain that this option is ignored for temp objects and do the same at the
> end of transaction, independently if commited or rolled back
>

I feel it differently - when I read ON COMMIT, then I expect really just a
COMMIT event, not ROLLBACK.  Attention - the metadata about variables are
transactional, but the variables are not transactional (by default).

But this feeling can be subjective. The objective argument against using ON
COMMIT like ON TRANSACTION END is fact, so we lost a possibility for a more
precious setting.

I can imagine scenarios with ON COMMIT RESET - and variable can hold some
last value from transaction, or ON ROLLBACK RESET - and variable can hold
some computed value from successfully ended transaction - last inserted id.

In this case, I don't see a problem to reopen a discussion about syntax or
postpone this feature. I think the possibility to reset variables at some
specified time can be an interesting feature (that can increase safety,
because the application doesn't need to solve initial setup),  but from the
list of implemented features for session variables, this is not too far
from the end. If TRANSACTION END is not intuitive - with exactly the same
functionality can be RESET AT TRANSACTION START - so the ON TRANSACTION END
can be transformed to ON BEGIN RESET, and this syntax can be maybe better,
because it signalize, for every transaction, the variable will be
initialized to default. What do you think? Can be ON BEGIN RESET acceptable
for you.

Regards

Pavel