Horton

Re: [HACKERS] proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Arthur Zakirov <a.zakirov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-18T11:54:44Z
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

I am sending rebased patch

2018-04-18 13:37 GMT+02:00 Arthur Zakirov <a.zakirov@postgrespro.ru>:

> On Tue, Apr 17, 2018 at 06:28:19PM +0200, Pavel Stehule wrote:
> > I though about it, and I am inclined to prefer pg_class instead separate
> > tables.
> >
> > It true, so there are lot of "unused" attributes for this purpose, but
> > there is lot of shared attributes, and lot of shared code. Semantically,
> I
> > see variables in family of sequences, tables, indexes, views. Now, it
> > shares code, and I hope in next steps more code can be shared -
> > constraints, triggers.
> >
> > There are two objective arguments for using pg_class:
> >
> > 1. unique name in schema - it reduces risk of collisions
> > 2. sharing lot of code
> >
> > So in this case I don't see well benefits of separate table.
>
> Understood. I haven't strong opinion here though. But I thought that
> pg_class approach may limit extensibility of variables.
>

I didn't touch limit (I don't know if there will be some issue - still is
far to upstream). This is technology, but workable, demo. I though so some
users had a problem to imagine what is persistent variable in my view.

But almost all code and tests can be used for final version - only storage
implementation is nothing more than workaround.


>
> BTW:
> - there is unitialized variable 'j' in pg_dump.c:15422
> - in tab-complete.c:1268 initialization needs extra NULL before
>   &Query_for_list_of_variables
>

I found it too today when I did rebase. But thank you for report.


>
> Also I think makeRangeVarForTargetOfSchemaVariable() has non friendly
> argument names 'field1', 'field2', 'field2'.
>

yes, I hadn't better names :(

In this routine I am doing diagnostic what semantic has sense for current
values. the field1, field2 can be schema.variable or variable.field. So
when I used semantic names: schema, varname, fieldname, then it was more
messy (for me).

Regards

Pavel


>
> --
> Arthur Zakirov
> Postgres Professional: http://www.postgrespro.com
> Russian Postgres Company
>