Horton

Re: [HACKERS] proposal: schema variables

Pavel Luzanov <p.luzanov@postgrespro.ru>

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

Hi,

I plan to make usability and feature test review in several days.

Is there any chances that it will work on replicas?
Such possibility is very helpful in generating reports.
Now, LET command produces an error:

ERROR:  cannot execute LET in a read-only transaction

But if we say that variables are non-transactional ?

-----
Pavel Luzanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On 08.03.2018 21:00, Pavel Stehule wrote:
> Hi
>
> 2018-02-07 7:34 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com 
> <mailto: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
>
>