Re: [HACKERS] proposal: schema variables - Mailing list pgsql-hackers

From Arthur Zakirov
Subject Re: [HACKERS] proposal: schema variables
Date
Msg-id 20180919112305.GA18604@zakirov.localdomain
Whole thread Raw
In response to Re: [HACKERS] proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] proposal: schema variables
Re: [HACKERS] proposal: schema variables
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: amul sul
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: schema variables