Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Znq-00061F-8F for pgsql-docs@arkaria.postgresql.org; Mon, 13 Jan 2014 05:11:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W2Znp-0006iL-Ov for pgsql-docs@arkaria.postgresql.org; Mon, 13 Jan 2014 05:11:09 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Znp-0006iF-2y for pgsql-docs@postgresql.org; Mon, 13 Jan 2014 05:11:09 +0000 Received: from mail-ea0-x22f.google.com ([2a00:1450:4013:c01::22f]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Znm-00059e-6y for pgsql-docs@postgresql.org; Mon, 13 Jan 2014 05:11:08 +0000 Received: by mail-ea0-f175.google.com with SMTP id z10so3053112ead.6 for ; Sun, 12 Jan 2014 21:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LYMY19061j54kFL/16ABQE2+DNSP/Fhar5GWBupzpro=; b=w9PSfWEzRxyjyb/nd0e52VtsDgvH57Q/yEArAlONGcPat3y58CS/iG6WLnduyGa8p7 MYR+2XlekfePjalV+4wEMQMBYCBrc4vw5kBuTkm72c1XYgr6E7dblKDDAFCZ/2Ih4Xft wRuJ2l5ylgqt4WpzcUww4+ZkgnmQa49pjKz0eX383co2TXr2A8hA4nvVZnB8ch4rPwk0 qFBtMWb/TeZDLfFAGZ+gb7zRO6aD+ZOfGTv84HtPyFJ3k0JVtYZLhFYZFdM6O/KwB8lK +iA0zoAmvNw9wRcmmjlRM3TpjzeeuK/Cw6yN4sY4Wx4242Kua8WCvjwMxrYOE4ZzFDtd lgIw== X-Received: by 10.14.193.132 with SMTP id k4mr24668031een.55.1389589865326; Sun, 12 Jan 2014 21:11:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.75.198 with HTTP; Sun, 12 Jan 2014 21:10:24 -0800 (PST) In-Reply-To: <20140113025904.GB22464@momjian.us> References: <20140111184106.GF28089@momjian.us> <24220.1389466350@sss.pgh.pa.us> <20140111190246.GG28089@momjian.us> <24577.1389467569@sss.pgh.pa.us> <20140112042306.GM28089@momjian.us> <20140113025904.GB22464@momjian.us> From: Pavel Stehule Date: Mon, 13 Jan 2014 06:10:24 +0100 Message-ID: Subject: Re: remove undocumented assign syntax from plpgsql doc To: Bruce Momjian Cc: Tom Lane , pgsql-docs Content-Type: multipart/alternative; boundary=047d7b3438444e6e1c04efd31ae2 X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --047d7b3438444e6e1c04efd31ae2 Content-Type: text/plain; charset=UTF-8 2014/1/13 Bruce Momjian > On Sun, Jan 12, 2014 at 07:00:09AM +0100, Pavel Stehule wrote: > > Comment updated. Patch attached. > > > > > > > > Still I am missing message about preferred syntax (or we should to > enhance GET > > DIAGNOSTICS doc about proprietary syntax). > > > > PL/pgSQL, PL/SQL is mix of two languages: ADA and SQL - and their > designers > > decided so embedded SQL statements will be placed in native SQL syntax > (and ADA > > in simplified ADA syntax) > > > > We have to find a agreement what we will prefer for PL/pgSQL: > > > > The assign statement is "ADA" statement - ":=" is preferred > > > > The GET DIAGNOSTICS is "SQL" statement - "=" is preferred > > > > A newer SQL/PSM was designed differently - without this dichotomy - A > > assignment is emphased by syntax SET varname = value > > > > A proper syntax is good information what is coming from - and It is good > mental > > helper to understand a philosophy of stored procedures (that shares > concepts > > with PL/SQL). Next argument is similarity with PL/SQL and SQL PL. This > > statement (GET DIAGNOSTICS) is supported on both environments and only > "=" is > > allowed there. > > I find the rules above so complex that I don't see how we can recommend > a best syntax. What I did in the patch I just posted was to put the > preferred operator first, but I don't see why we want to get into these > details in the docs. > just a note about preferred variant should be ok. Using ':=' in GET DIAGNOSTICS statement is just bad idea. Pavel > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + Everyone has their own god. + > --047d7b3438444e6e1c04efd31ae2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



2014/1/13 Bruce Momjian <bruce@momjian.us>
On Sun, Jan 12, 2014 at 07:00:09AM +0100, Pavel Stehule w= rote:
> =C2=A0 =C2=A0 Comment updated. =C2=A0Patch attached.
>
>
>
> Still I am missing message about preferred syntax (or we should to enh= ance GET
> DIAGNOSTICS doc about proprietary syntax).
>
> PL/pgSQL, PL/SQL is mix of two languages: ADA and SQL - and their desi= gners
> decided so embedded SQL statements will be placed in native SQL syntax= (and ADA
> in simplified ADA syntax)
>
> We have to find a agreement what we will prefer for PL/pgSQL:
>
> The assign statement is "ADA" statement - ":=3D" i= s preferred
>
> The GET DIAGNOSTICS is "SQL" statement - "=3D" is = preferred
>
> A newer SQL/PSM was designed differently - without this dichotomy - A<= br> > assignment is emphased by syntax SET varname =3D value
> =C2=A0
> A proper syntax is good information what is coming from - and It is go= od mental
> helper to understand a philosophy of stored procedures (that shares co= ncepts
> with PL/SQL). Next argument is similarity with PL/SQL and SQL PL. This=
> statement (GET DIAGNOSTICS) is supported on both environments and only= "=3D" is
> allowed there.

I find the rules above so complex that I don't see how we can rec= ommend
a best syntax. =C2=A0What I did in the patch I just posted was to put the preferred operator first, but I don't see why we want to get into these=
details in the docs.

just a note about = preferred variant should be ok. Using ':=3D' in GET DIAGNOSTICS sta= tement is just bad idea.

Pavel
=C2=A0
=

--
=C2=A0 Bruce Momjian =C2=A0<bruce@mo= mjian.us> =C2=A0 =C2=A0 =C2=A0 =C2=A0http://momjian.us
=C2=A0 EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com

=C2=A0 + Everyone has their own god. +

--047d7b3438444e6e1c04efd31ae2--