Horton

Re: proposal: schema variables

Wolfgang Walther <walther@technowledgy.de>

View thread
From: Wolfgang Walther <walther@technowledgy.de>
To: Pavel Stehule <pavel.stehule@gmail.com>
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-16T17:13:38Z
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.

Pavel Stehule:
> (global (temp)) table can hold 0, 1 or more rows (and rows are always 
> composite of 0..n fields). The variable holds a value of some type. 
> Proposed session variables are like plpgsql variables (only with 
> different scope). In Postgres there is a difference between a scalar 
> variable and composite variable with one field. 

I can store composite values in table columns, too. A table column can 
either be scalar or composite in that sense.

So, maybe rephrase: Single-row, single-column (global (temp)) table = 
variable. One "cell" of that table.

For me, the major difference between a variable and a table is, that the 
table has 0...n rows and 0...m columns, while the variable has *exactly* 
one in both cases, not 0 either.

I must put tables into FROM, why not those nice mini-tables called 
variables as well? Because they are potentially scalar, you say!

But: I can already put functions returning scalar values into FROM:

   SELECT * FROM format('hello');

The function returns a plain string only.

I don't know. This just "fits" for me.

Or to put it differently: I don't really care whether I have to write 
"(SELECT variable FROM variable)" instead of just "variable". I don't 
want session variables for the syntax, I want session variables, because 
they are **so much better** than custom GUCs.

Best,

Wolfgang