Re: [HACKERS] proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>, Pavel Luzanov <p.luzanov@postgrespro.ru>
Cc: Pavel Golub <pavel@gf.microolap.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-08T18:00:36Z
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

2018-02-07 7:34 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

> Hi
>
> updated patch with your changes in documentation and pg_dump (initial)
> support
>
> Main issue of this patch is storage. We can reuse local buffers used for
> temp tables. But it does allocation by 8KB and it creates temp files for
> every object. That is too big overhead. Storing just in session memory is
> too simple - then there should be lot of new code used, when variable will
> be dropped.
>
> I have ideas how to allow work with mix of scalar and composite types - so
> it will be next step of this prototype.
>
> Regards
>
> Pavel
>

new update - rebased, + some initial support for composite values on right
side and custom types, arrays are supported too.

omega=# CREATE VARIABLE xx AS (a int, b numeric);
CREATE VARIABLE
omega=# LET xx = (10, 20)::xx;
LET
omega=# SELECT xx;
+---------+
|   xx    |
+---------+
| (10,20) |
+---------+
(1 row)

omega=# SELECT xx.a + xx.b;
+----------+
| ?column? |
+----------+
|       30 |
+----------+
(1 row)

omega=# \d xx
schema variable "public.xx"
+--------+---------+
| Column |  Type   |
+--------+---------+
| a      | integer |
| b      | numeric |
+--------+---------+


Regards

Pavel