Re: proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

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>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-01T22:02:27Z
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

čt 1. 8. 2024 v 13:22 odesílatel Laurenz Albe <laurenz.albe@cybertec.at>
napsal:

> On Thu, 2024-08-01 at 08:12 +0200, Pavel Stehule wrote:
> > fresh rebase + fix format in doc
>
> Thanks!
>
> I'm curious, but too lazy to build the patch now, so I'm asking:
> what did you do about this error?
>
> > CREATE VARIABLE var AS date;
> > LET var = current_date;
> > PREPARE stmt(date) AS SELECT $1;
> > EXECUTE stmt(var);
> > ERROR:  paramid of PARAM_VARIABLE param is out of range
>
> Or does a later patch take care of that?
>

It is working with patch "allow read an value of session variable directly
from  expression executor"

It looks very similar to evaluation of parameters of CALL statements.
Without the mentioned patch, the CALL statements don't allow variables as
an argument. I blocked usage of session variables as EXECUTE parameters
until direct access to session variables in expression evaluation is
supported.

Regards

Pavel






> Yours,
> Laurenz Albe
>