Horton

Re: proposal: schema variables

Laurenz Albe <laurenz.albe@cybertec.at>

View thread
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: 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-09-02T14:00:51Z
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.

On Thu, 2024-08-29 at 19:33 +0200, Pavel Stehule wrote:
> > > > >   > +   /*
> > > > >   > +    * Although svar is freshly validated in this point, the svar->is_valid can
> > > > >   > +    * be false, due possible accepting invalidation message inside domain
> > > > >   > +    * check. Now, the validation is done after lock, that can also accept
> > > > >   > +    * invalidation message, so validation should be trustful.
> > > > >   > +    *
> > > > >   > +    * For now, we don't need to repeat validation. Only svar should be valid
> > > > >   > +    * pointer.
> > > > >   > +    */
> > > > 
> > > > This comment is related to assertions. Before I had there `Assert(svar->is_valid)`,
> > > > because I expected it. But it was not always true. And although it is true,
> > > > we don't need to validate a variable, because at this moment, the variable
> > > > should be locked, and then we can return content safely.
> > > 
> > > I guess my main problem is the word "trustful".  I don't recognize that word.
> > > Perhaps you can reword the comment along the lines of your above explanation.
> > 
> > 
> > I'll try to change it
> 
> is this better
> 
> <-->/*
> <--> * Although svar is freshly validated in this point, the svar->is_valid can
> <--> * be false, due possible accepting invalidation message inside domain
> <--> * check. But now, the variable, and all dependencies are locked, so we
> <--> * don't need to repeat validation.
> <--> */

Much better.

Here is an improved version:

  Although "svar" is freshly validated in this point, svar->is_valid can
  be false, if an invalidation message ws processed during the domain check.
  But the variable and all its dependencies are locked now, so we don't need
  to repeat the validation.

Yours,
Laurenz Albe