Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j7Ko0-0001Ap-TW for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Feb 2020 15:10:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j7Knz-0003xp-Gm for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Feb 2020 15:10:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j7Knz-0003xh-4s for pgsql-hackers@lists.postgresql.org; Thu, 27 Feb 2020 15:10:27 +0000 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j7Knw-0005Fj-I4 for pgsql-hackers@lists.postgresql.org; Thu, 27 Feb 2020 15:10:26 +0000 Received: by mail-lj1-x229.google.com with SMTP id d10so3811358ljl.9 for ; Thu, 27 Feb 2020 07:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U9v2JFoktfP2pz+C5AZqe6eZuhCgAIGP0nnNWeDxiq4=; b=XcCreglGCbIPlkBKnlALAnCi2iHuprRoyco52ZgSpr7aiVAi4bYPz4oBSOWda4x1w/ 7VPXK6oYvFd6PggtfWMsINeDGjM0o9uHJuXpFv3KPkOTFhuCZIateFsglxYXwNSDWXex BsJh4eJsjk3oNpw+d7/uBPThjWF1jnN5lNtRVdvaQ4ftb4LV7pTuQ6bbZPuCN1y+t+WJ YGpkBoYQGkly8ouGOYZmRBH5f/AeHvUpSc+jxkHYy06GSEZUd8ZH8NwnUzwYTuplts9h Zbe/YTZAxdu+B46HkVjrxhx6o+RI2fBQaTddUnSWxsZI5iIUBwCzS+rAPPlO6qyqGONf uF3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U9v2JFoktfP2pz+C5AZqe6eZuhCgAIGP0nnNWeDxiq4=; b=f9a9Lu3iP+2npHgGQn9THjr4mS8gdH3Gjf1c7O10f+fmn3MxXn09tdqgQatsu4MQ8Q 9ZQ/SpZhcGSZnUASuzxfWYqUYDgejbmhf8PfNr8e6qOCnFAABYBKQMFe0wLxQ3GCS8Qj Wo5FX76VJaMrSs6vc/YDK+cNCFEyw7IBtVBVoRw4RuInqRZAqRnQLZqnCtnyrHwlgH+X tdrDcylbP6uVxPSEKSbcKWMINY74CdAPl44EPYhzkupZ5eiD2133ADLe0dRQ0jvOaf1m Si/CHYQq/u7cMVSFxkxKR0N1foyHFA9JTLkZFirpE2ApNP13X2rgBXpxxFmGWHPb2MC2 nx9A== X-Gm-Message-State: ANhLgQ3RqQ2BbFplnfv0+PrCRz/c5AvjlNr4XIlonrAPwUMKDJdefrwZ LDKauDpMaBAjwvDqZ9XilvyhtQA8iWryox18LsY= X-Google-Smtp-Source: ADFU+vt3jN8XGqen8ogwqqs75rApXWBuCa0LS1JjO9lbB9W5uVNMM3nlOQkiEtizYwukyspiwC4BT2TGb7JbjaDAmg0= X-Received: by 2002:a2e:870b:: with SMTP id m11mr3178327lji.93.1582816222748; Thu, 27 Feb 2020 07:10:22 -0800 (PST) MIME-Version: 1.0 References: <158272883575.1651.2316685587547965508.pgcf@coridan.postgresql.org> In-Reply-To: From: Pavel Stehule Date: Thu, 27 Feb 2020 16:09:44 +0100 Message-ID: Subject: Re: proposal: schema variables To: DUVAL REMI Cc: PostgreSQL Hackers , "phb07@apra.asso.fr" Content-Type: multipart/alternative; boundary="000000000000b3a21a059f901e46" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000b3a21a059f901e46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C4=8Dt 27. 2. 2020 v 15:59 odes=C3=ADlatel DUVAL REMI napsal: > Hello Pavel. > > > > That looks pretty good to me ! > > > > I=E2=80=99m adding Philippe Beaudoin who was also interested in this topi= c. > > > > Recap : We were looking for a way to separate variable from constants in > the =E2=80=9CSchema Variables=E2=80=9D proposition from Pavel. > > Pavel was saying that there are some limitations regarding the keywords w= e > can use, as the community don=E2=80=99t want to introduce too much new ke= ywords in > Postgres SQL (PL/pgSQL is a different list of keywords). > > =E2=80=9CCONSTANT=E2=80=9D is not a keyword in SQL for Now (though it is = one in PL/pgSQL). > > Pavel=E2=80=99s syntax allow to use it as a keyword in the =E2=80=9CWITH = OPTIONS=E2=80=9D clause > that is already supported. > > =E2=80=A6 I think it=E2=80=99s a good idea. > > > > The list of keywords is defined in : postgresql\src\include\parser\kwlist= .h > > > > Pavel, I saw that in DB2, those variables are called =E2=80=9CGlobal Vari= ables=E2=80=9D, > is it something we can consider changing, or do you prefer to keep using > the =E2=80=9CSchema Variable=E2=80=9D name ? > It is most hard question. Global variables has sense, but when we will use it in plpgsql, then this name can be little bit confusing. Personally I prefer "schema variable" although my opinion is not too strong. This name more signalize so this is more generic, more database related than some special kind of plpgsql variables. Now, I think so maybe is better to use schema variables, because there is different syntax then global temp tables. Variables are global by design. So in this moment I prefer the name "schema variables". It can be used as global variables in plpgsql, but it is one case. Pavel > > > > *De :* Pavel Stehule [mailto:pavel.stehule@gmail.com] > *Envoy=C3=A9 :* jeudi 27 f=C3=A9vrier 2020 15:38 > *=C3=80 :* DUVAL REMI > *Cc :* PostgreSQL Hackers > *Objet :* Re: proposal: schema variables > > > > > > Hi > > > > > 3) Any way to define CONSTANTs ? > We already talked a bit about this subject and also Gilles Darold > introduces it in this mailing-list topic but I'd like to insist on it. > I think it would be nice to have a way to say that a variable should not > be changed once defined. > Maybe it's hard to implement and can be implemented later, but I just wan= t > to know if this concern is open. > > > > I played little bit with it and I didn't find any nice solution, but mayb= e > I found the solution. I had ideas about some variants, but almost all tim= e > I had a problem with parser's shifts because all potential keywords are n= ot > reserved. > > > > last variant, but maybe best is using keyword WITH > > > > So the syntax can looks like > > > > CREATE [ TEMP ] VARIABLE varname [ AS ] type [ NOT NULL ] [ DEFAULT > expression ] [ WITH [ OPTIONS ] '(' ... ')' ] ] > > > > What do you think about this syntax? It doesn't need any new keyword, and > it easy to enhance it. > > > > CREATE VARIABLE foo AS int DEFAULT 10 WITH OPTIONS ( CONSTANT); > > > > ? > > > > Regards > > > > Pavel > > > > > --000000000000b3a21a059f901e46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=C4=8Dt 27. 2. 2020 v=C2=A015:59 odes= =C3=ADlatel DUVAL REMI <REMI.DUV= AL@cheops.fr> napsal:

Hello Pavel.

=C2=A0

That looks pretty= good to me=C2=A0!

=C2=A0<= /u>

I=E2=80=99m addin= g Philippe Beaudoin who was also interested in this topic.

=C2=A0<= /u>

Recap : We were l= ooking for a way to separate variable from constants in the =E2=80=9CSchema= Variables=E2=80=9D proposition from Pavel.

Pavel was saying = that there are some limitations regarding the keywords we can use, as the c= ommunity don=E2=80=99t want to introduce too much new keywords in Postgres SQL (PL/pgSQL is a different list of key= words).

=E2=80=9CCONSTANT= =E2=80=9D is not a keyword in SQL for Now (though it is one in PL/pgSQL).

Pavel=E2=80=99s s= yntax allow to use it as a keyword in the =E2=80=9CWITH OPTIONS=E2=80=9D cl= ause that is already supported.

=E2=80=A6 I think= it=E2=80=99s a good idea.

=C2=A0<= /u>

The list of keywo= rds is defined in : postgresql\src\include\parser\kwlist.h

=C2=A0<= /u>

Pavel, I saw that= in DB2, those variables are called =E2=80=9CGlobal Variables=E2=80=9D, is = it something we can consider changing, or do you prefer to keep using the =E2=80=9CSchema Variable=E2=80=9D name ?


It is most hard quest= ion. Global variables has sense, but when we will use it in plpgsql, then t= his name can be little bit confusing. Personally I prefer "schema vari= able" although my opinion is not too strong. This name more signalize = so this is more generic, more database related than some special kind of pl= pgsql variables. Now, I think so maybe is better to use schema variables, b= ecause there is different syntax then global temp tables. Variables are glo= bal by design. So in this moment I prefer the name "schema variables&q= uot;. It can be used as global variables in plpgsql, but it is one case.

Pavel


=C2=A0<= /u>

=C2=A0<= /u>

De=C2=A0: Pavel Stehule [mailto:pavel.stehule@gmail.c= om]
Envoy=C3=A9=C2=A0: jeudi 27 f=C3=A9vrier 2020 15:38
=C3=80=C2=A0: DUVAL REMI <REMI.DUVAL@CHEOPS.FR>
Cc=C2=A0: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org= >
Objet=C2=A0: Re: proposal: schema variables

=C2=A0

=C2=A0

Hi

=C2=A0


3) Any way to define CONSTANTs ?
We already talked a bit about this subject and also Gilles Darold introduce= s it in this mailing-list topic but I'd like to insist on it.
I think it would be nice to have a way to say that a variable should not be= changed once defined.
Maybe it's hard to implement and can be implemented later, but I just w= ant to know if this concern is open.

=C2=A0

I played little bit with it and I didn't find an= y nice solution, but maybe I found the solution. I had ideas about some var= iants, but almost all time I had a problem with parser's shifts because= all potential keywords are not reserved.

=C2=A0

last variant, but maybe best is using keyword WITH

=C2=A0

So the syntax can looks like

=C2=A0

CREATE [ TEMP ] VARIABLE varname [ AS ] type [ NOT N= ULL ] [ DEFAULT expression ] [ WITH [ OPTIONS ] '(' ... ')'= ] ]

=C2=A0

What do you think about this syntax? It doesn't = need any new keyword, and it easy to enhance it.

=C2=A0

CREATE VARIABLE foo AS int DEFAULT 10 WITH OPTIONS (= CONSTANT);

=C2=A0

?

=C2=A0

Regards

=C2=A0

Pavel

=C2=A0

=C2=A0

--000000000000b3a21a059f901e46--