Re: [HACKERS] proposal: schema variables

2017-11-13 Thread Pavel Stehule
Hi 2017-11-13 13:15 GMT+01:00 Pavel Golub : > Hello, Pavel. > > You wrote: > > PS> Hi, > > PS> I propose a new database object - a variable. The variable is > PS> persistent object, that holds unshared session based not > PS> transactional in memory value of any type. Like

Re: [HACKERS] proposal: schema variables

2017-11-13 Thread Pavel Golub
Hello, Pavel. You wrote: PS> Hi, PS> I propose a  new database object - a variable. The variable is PS> persistent object, that holds unshared session based not PS> transactional in memory value of any type. Like variables in any PS> other languages. The persistence is required for possibility

Re: [HACKERS] proposal: schema variables

2017-11-03 Thread Chris Travers
Some thoughts on this. On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane wrote: > Nico Williams writes: > > With access controls, GUCs could become schema variables, and settings > > from postgresql.conf could move into the database itself (which I think > >

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Nico Williams
On Thu, Nov 02, 2017 at 11:48:44AM -0400, Tom Lane wrote: > Nico Williams writes: > > With access controls, GUCs could become schema variables, and settings > > from postgresql.conf could move into the database itself (which I think > > would be nice). > > People

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Robert Haas
On Thu, Nov 2, 2017 at 9:05 PM, Nico Williams wrote: >> Overloading SET to handle both variables and GUCs seems likely to >> create problems, possibly including security problems. For example, >> maybe a security-definer function could leave behind variables to >> trick

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Pavel Stehule
2017-11-02 13:35 GMT+01:00 Robert Haas : > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule > wrote: > > The variables can be modified by SQL command SET (this is taken from > > standard, and it natural) > > > > SET varname = expression; > >

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Tom Lane
Nico Williams writes: > With access controls, GUCs could become schema variables, and settings > from postgresql.conf could move into the database itself (which I think > would be nice). People re-propose some variant of that every so often, but it never works, because it

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Pavel Stehule
2017-11-02 16:07 GMT+01:00 Craig Ringer : > On 26 October 2017 at 15:21, Pavel Stehule > wrote: > > Hi, > > > > I propose a new database object - a variable. > > Didn't we have a pretty long discussion about this already in > > Yeah. > >

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Pavel Stehule
2017-11-02 16:35 GMT+01:00 Nico Williams : > On Thu, Nov 02, 2017 at 06:05:54PM +0530, Robert Haas wrote: > > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule > wrote: > > > The variables can be modified by SQL command SET (this is taken from > > >

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Nico Williams
On Thu, Nov 02, 2017 at 06:05:54PM +0530, Robert Haas wrote: > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule > wrote: > > The variables can be modified by SQL command SET (this is taken from > > standard, and it natural) > > > > SET varname = expression; > >

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Craig Ringer
On 26 October 2017 at 15:21, Pavel Stehule wrote: > Hi, > > I propose a new database object - a variable. Didn't we have a pretty long discussion about this already in Yeah.

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Robert Haas
On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule wrote: > The variables can be modified by SQL command SET (this is taken from > standard, and it natural) > > SET varname = expression; Overloading SET to handle both variables and GUCs seems likely to create problems,

Re: [HACKERS] proposal: schema variables

2017-11-01 Thread Gilles Darold
Le 01/11/2017 à 05:15, Pavel Stehule a écrit : > > > 2017-10-31 22:28 GMT+01:00 srielau >: > > Pavel, > > There is no > DECLARE TEMP CURSOR > or > DECLARE TEMP variable in PLpgSQL > and > > > sure .. DECLARE TEMP has no sense, I

Re: [HACKERS] proposal: schema variables

2017-11-01 Thread Pavel Stehule
2017-11-01 19:03 GMT+01:00 Mark Dilger : > > > Comments, notes? > > How would variables behave on transaction rollback? > > CREATE TEMP VARIABLE myvar; > SET myvar := 1; > BEGIN; > SET myvar := 2; > COMMIT; > BEGIN; > SET myvar := 3; > ROLLBACK; > SELECT myvar; > > How

Re: [HACKERS] proposal: schema variables

2017-11-01 Thread Mark Dilger
> Comments, notes? How would variables behave on transaction rollback? CREATE TEMP VARIABLE myvar; SET myvar := 1; BEGIN; SET myvar := 2; COMMIT; BEGIN; SET myvar := 3; ROLLBACK; SELECT myvar; How would variables behave when modified in a procedure that aborts rather than returning cleanly?

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Pavel Stehule
2017-11-01 6:07 GMT+01:00 Serge Rielau : > "Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL > standard, the effect is not the same. In the standard, temporary tables are > defined just once and automatically exist (starting with empty contents) in > every

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Serge Rielau
" Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL standard, the effect is not the same. In the standard, temporary tables are defined just once and automatically exist (starting with empty contents) in every session that needs them. PostgreSQL instead requires each

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Pavel Stehule
2017-10-31 22:28 GMT+01:00 srielau : > Pavel, > > There is no > DECLARE TEMP CURSOR > or > DECLARE TEMP variable in PLpgSQL > and > sure .. DECLARE TEMP has no sense, I talked about similarity DECLARE and CREATE TEMP CREATE TEMP TABLE has a different meaning from what I

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Gilles Darold
Le 31/10/2017 à 23:36, Gilles Darold a écrit : > Le 31/10/2017 à 22:28, srielau a écrit : >> Pavel, >> >> There is no >> DECLARE TEMP CURSOR >> or >> DECLARE TEMP variable in PLpgSQL >> and >> CREATE TEMP TABLE has a different meaning from what I understand you >> envision for variables. >> >> But

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Gilles Darold
Le 31/10/2017 à 22:28, srielau a écrit : > Pavel, > > There is no > DECLARE TEMP CURSOR > or > DECLARE TEMP variable in PLpgSQL > and > CREATE TEMP TABLE has a different meaning from what I understand you > envision for variables. > > But maybe I'm mistaken. Your original post did not describe the

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread srielau
Pavel, There is no DECLARE TEMP CURSOR or DECLARE TEMP variable in PLpgSQL and CREATE TEMP TABLE has a different meaning from what I understand you envision for variables. But maybe I'm mistaken. Your original post did not describe the entire syntax: CREATE [TEMP] VARIABLE [IF NOT EXISTS] name

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Pavel Stehule
2017-10-31 22:08 GMT+01:00 Serge Rielau : > Pavel, > > I can imagine, so DECLARE command will be introduced as short cut for > CREATE TEMP VARIABLE, but in this moment I would not to open this topic. I > afraid of bikeshedding and I hope so CREATE TEMP VAR is anough. > >

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Serge Rielau
Pavel, I can imagine, so DECLARE command will be introduced as short cut for CREATE TEMP VARIABLE, but in this moment I would not to open this topic. I afraid of bikeshedding and I hope so CREATE TEMP VAR is anough. Language is important because language stays. You choice of syntax will

Re: [HACKERS] proposal: schema variables

2017-10-31 Thread Pavel Stehule
Hi 2017-10-30 22:42 GMT+01:00 srielau : > Pavel, > > I wouldn't put in the DROP option. > Or at least not in that form of syntax. > > By convention CREATE persists DDL and makes object definitions visible > across sessions. > DECLARE defines session private objects which cannot

Re: [HACKERS] proposal: schema variables

2017-10-30 Thread srielau
Pavel, I wouldn't put in the DROP option. Or at least not in that form of syntax. By convention CREATE persists DDL and makes object definitions visible across sessions. DECLARE defines session private objects which cannot collide with other sessions. If you want variables with a short lifetime

Re: [HACKERS] proposal: schema variables

2017-10-30 Thread Hannu Krosing
but you can always do with a (id, value) as ( values (1, 'foo'), (2, 'bar'), (3, 'baz') ) select set_config('custom.value',(select value from a where id = 2),true); if you are worried about the evaluation order On 29 October 2017 at 09:51, Chris Travers wrote: > >

Re: [HACKERS] proposal: schema variables

2017-10-29 Thread Chris Travers
On Sat, Oct 28, 2017 at 4:56 PM, Pavel Stehule wrote: > >> > The creating database objects and necessary infrastructure is the most > simple task of this project. I'll be more happy if there are zero > intersection because variables and GUC are designed for different

Re: [HACKERS] proposal: schema variables

2017-10-28 Thread Pavel Stehule
Hi 2017-10-28 16:24 GMT+02:00 Chris Travers : > > > On Thu, Oct 26, 2017 at 9:21 AM, Pavel Stehule > wrote: > >> Hi, >> >> I propose a new database object - a variable. The variable is persistent >> object, that holds unshared session based

Re: [HACKERS] proposal: schema variables

2017-10-28 Thread Chris Travers
On Thu, Oct 26, 2017 at 9:21 AM, Pavel Stehule wrote: > Hi, > > I propose a new database object - a variable. The variable is persistent > object, that holds unshared session based not transactional in memory value > of any type. Like variables in any other languages.

Re: [HACKERS] proposal: schema variables

2017-10-27 Thread Pavel Stehule
2017-10-27 15:38 GMT+02:00 Gilles Darold : > Le 26/10/2017 à 09:21, Pavel Stehule a écrit : > > Hi, > > > > I propose a new database object - a variable. The variable is > > persistent object, that holds unshared session based not transactional > > in memory value of

Re: [HACKERS] proposal: schema variables

2017-10-27 Thread Gilles Darold
Le 26/10/2017 à 09:21, Pavel Stehule a écrit : > Hi, > > I propose a  new database object - a variable. The variable is > persistent object, that holds unshared session based not transactional > in memory value of any type. Like variables in any other languages. > The persistence is required for

Re: [HACKERS] proposal: schema variables

2017-10-27 Thread Pavel Stehule
2017-10-27 7:47 GMT+02:00 Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com>: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Pavel Stehule > > I propose a new database object - a variable. The variable is persistent > > object, that

Re: [HACKERS] proposal: schema variables

2017-10-26 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Pavel Stehule > I propose a new database object - a variable. The variable is persistent > object, that holds unshared session based not transactional in memory value > of any type. Like variables

Re: [HACKERS] proposal: schema variables

2017-10-26 Thread Tatsuo Ishii
> Hi, > > I propose a new database object - a variable. The variable is persistent > object, that holds unshared session based not transactional in memory value > of any type. Like variables in any other languages. The persistence is > required for possibility to do static checks, but can be

Re: [HACKERS] proposal: schema variables

2017-10-26 Thread Pavel Stehule
Hi 2017-10-27 0:07 GMT+02:00 Nico Williams : > On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote: > > Comments, notes? > > I like it. > > I would further like to move all of postgresql.conf into the database, > as much as possible, as well as pg_ident.conf and

Re: [HACKERS] proposal: schema variables

2017-10-26 Thread Nico Williams
On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote: > Comments, notes? I like it. I would further like to move all of postgresql.conf into the database, as much as possible, as well as pg_ident.conf and pg_hba.conf. Variables like current_user have a sort of nesting context