public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Arthur Zakirov <a.zakirov@postgrespro.ru>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Gilles Darold <gilles.darold@dalibo.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [HACKERS] proposal: schema variables
Date: Wed, 19 Sep 2018 14:23:06 +0300
Message-ID: <20180919112305.GA18604@zakirov.localdomain> (raw)
In-Reply-To: <CAFj8pRCZuq=0MRsYrNzBqxPx5fqmKFN3i-BsPo8j=yW6N_=WDA@mail.gmail.com>
References: <CAFj8pRCRUpNjX9Fb49SaADbRnCE69ndkOvtoeKxwvxetfJ8=kA@mail.gmail.com>
<alpine.DEB.2.21.1808220831550.10677@lancre>
<CAFj8pRCyvx37Fnw6yHdscGbbGo_Ak3WdeKiZ6arFW8JTA099YA@mail.gmail.com>
<alpine.DEB.2.21.1808230927090.31897@lancre>
<CAFj8pRAcFv09qOcbr09c2AbwZ9DGw5Hs6rPcYoo7r9OLdWWB2A@mail.gmail.com>
<CAEZATCVy77hhgTZ1Yrvbp6GbsUuWY0Bw8CLbv_Jr2mAF_bOkBA@mail.gmail.com>
<CAFj8pRDREykg0hnMBkryBmSTtqEs9QUKUp_447_F5P1j8bkH1w@mail.gmail.com>
<CAFj8pRBkPswn0JA8U3vFOdBGqcBu0ZM7jC7JcDdCS1EbZfzb2A@mail.gmail.com>
<CAFj8pRAi2Xd93ae-SsnMOC5W4hWenmkftTnCrHgdcPpvbOs1bg@mail.gmail.com>
<CAFj8pRCZuq=0MRsYrNzBqxPx5fqmKFN3i-BsPo8j=yW6N_=WDA@mail.gmail.com>
Hello,
On Wed, Sep 19, 2018 at 10:30:31AM +0200, Pavel Stehule wrote:
> Hi
>
> new update:
>
> I fixed pg_restore, and I cleaned a code related to transaction processing
>
> There should be a full functionality now.
I reviewed a little bit the patch. I have a few comments.
> <title><structname>pg_views</structname> Columns</title>
I think there is a typo here. It should be "pg_variable".
> GRANT { READ | WRITE | ALL [ PRIVILEGES ] }
Shouldn't we use here GRANT { SELECT | LET | ... } syntax for the
constistency. Same for REVOKE. I'm not experienced syntax developer
though. But we use SELECT and LET commands when working with variables.
So we should GRANT and REVOKE priveleges for this commands.
> [ { ON COMMIT DROP | ON TRANSACTION END RESET } ]
I think we may join them and have the syntax { ON COMMIT DROP | RESET }
to get more simpler syntax. If we create a variable with ON COMMIT
DROP, PostgreSQL will drop it regardless of whether transaction was
committed or rollbacked:
=# ...
=# begin;
=# create variable int1 int on commit drop;
=# rollback;
=# -- There is no variable int1
CREATE TABLE syntax has similar options [1]. ON COMMIT controls
the behaviour of temporary tables at the end a transaction block,
whether it was committed or rollbacked. But I'm not sure is this a good
example of precedence.
> - ONCOMMIT_DROP /* ON COMMIT DROP */
> + ONCOMMIT_DROP, /* ON COMMIT DROP */
> } OnCommitAction;
There is the extra comma here after ONCOMMIT_DROP.
1 - https://www.postgresql.org/docs/current/static/sql-createtable.html
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: a.zakirov@postgrespro.ru, pavel.stehule@gmail.com, dean.a.rasheed@gmail.com, coelho@cri.ensmp.fr, gilles.darold@dalibo.com, pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] proposal: schema variables
In-Reply-To: <20180919112305.GA18604@zakirov.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox