Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2E6W-0005tR-9F for pgsql-docs@arkaria.postgresql.org; Sun, 12 Jan 2014 06:01:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W2E6V-0001qV-M5 for pgsql-docs@arkaria.postgresql.org; Sun, 12 Jan 2014 06:00:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2E6U-0001qO-IE for pgsql-docs@postgresql.org; Sun, 12 Jan 2014 06:00:58 +0000 Received: from mail-ee0-x230.google.com ([2a00:1450:4013:c00::230]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2E6M-0003hr-T2 for pgsql-docs@postgresql.org; Sun, 12 Jan 2014 06:00:57 +0000 Received: by mail-ee0-f48.google.com with SMTP id t10so858549eei.21 for ; Sat, 11 Jan 2014 22:00:50 -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=hmeqyHpngF3U3+a3YUFb1JzLGaWF8s1/IYeTNXlLOxs=; b=B9xopAHUY0roltsCk4uylOaN5a0m5I4PVXMiXPPHNx5iY4/v9ZXx7l+5m8nFwwPMcP Q8faQ0EtRHKtGhzf+R8j+cWbBMgXdY1qb0iAvB+UurBwL9OwXN6GrVdd+5v4S+ZhRtmv 5Z9a4MMIUwRk/xC4PvtRquz1kyOjWASE4aIAZfZW30KYaTKg+Z0BtUxiG8Ab1/jnwj2z z4ZpipoRiQmq9zuAENOsuIEforZPD5ZVgtsGDMX+3KedYQHdy5cwgIeGv+lSRPjxlZew JSnIgnHCwsZejEzfRQs9Pdjc1qe4zVvAB40mmd6x/CwA3ZnbmnGBDwxORLXoKnG0BWjK zouw== X-Received: by 10.15.10.65 with SMTP id f41mr19740129eet.84.1389506450201; Sat, 11 Jan 2014 22:00:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.75.198 with HTTP; Sat, 11 Jan 2014 22:00:09 -0800 (PST) In-Reply-To: <20140112042306.GM28089@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> From: Pavel Stehule Date: Sun, 12 Jan 2014 07:00:09 +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=001a11c3e56660a20d04efbfaeea 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 --001a11c3e56660a20d04efbfaeea Content-Type: text/plain; charset=UTF-8 2014/1/12 Bruce Momjian > On Sat, Jan 11, 2014 at 10:06:27PM +0100, Pavel Stehule wrote: > > > > > > > > 2014/1/11 Tom Lane > > > > Bruce Momjian writes: > > > Oh, I think you are right. I have reverted the patch. Attached is > > > proposed documentation for '='. > > > > Meh. Variable initialization is only one of multiple cases > (assignment, > > GET DIAGNOSTICS; maybe others, I've not examined the grammar). Also, > > if we do it like this, we're implying that both := and = are equally > > preferred, which might not be the impression we want to leave. > > > > > > GET DIAGNOSTICS is defined by standard - and there "=" should be allowed > only - > > although we allow ":=" too. It is a embedded SQL statement - although it > is > > implemented as plpgsql statement. > > OK, docs updated for that. I assume OPEN and FOR also can take := or =, > right? > > > Same situation is with UPDATE statement - we don't allow ":=" there. > > > > > > > > I'd be a bit inclined to just stick a NOTE somewhere saying that "=" > > can be used in place of ":=" for assignment. > > > > > > ok > > > > If we accept it and we close this topic, then following comment should be > > removed > > > > assign_operator : '=' /* not documented because it might be removed > someday * > > 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. Regards Pavel > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + Everyone has their own god. + > --001a11c3e56660a20d04efbfaeea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



2014/1/12 Bruce Momjian <bruce@momjian.us>
On Sat, Jan 11, 2014 at 10:06:27PM +0100, Pavel Stehule w= rote:
>
>
>
> 2014/1/11 Tom Lane <tgl@sss.pg= h.pa.us>
>
> =C2=A0 =C2=A0 Bruce Momjian <br= uce@momjian.us> writes:
> =C2=A0 =C2=A0 > Oh, I think you are right. =C2=A0I have reverted th= e patch. =C2=A0Attached is
> =C2=A0 =C2=A0 > proposed documentation for '=3D'.
>
> =C2=A0 =C2=A0 Meh. =C2=A0Variable initialization is only one of multip= le cases (assignment,
> =C2=A0 =C2=A0 GET DIAGNOSTICS; maybe others, I've not examined the= grammar). =C2=A0Also,
> =C2=A0 =C2=A0 if we do it like this, we're implying that both :=3D= and =3D are equally
> =C2=A0 =C2=A0 preferred, which might not be the impression we want to = leave.
>
>
> GET DIAGNOSTICS is defined by standard - and there "=3D" sho= uld be allowed only -
> although we allow ":=3D" too. It is a embedded SQL statement= - although it is
> implemented as plpgsql statement.

OK, docs updated for that. =C2=A0I assume OPEN and FOR also can take = :=3D or =3D,
right?

> Same situation is with UPDATE statement - we don't allow ":= =3D" there.
> =C2=A0
>
>
> =C2=A0 =C2=A0 I'd be a bit inclined to just stick a NOTE somewhere= saying that "=3D"
> =C2=A0 =C2=A0 can be used in place of ":=3D" for assignment.=
>
>
> ok
>
> If we accept it and we close this topic, then following comment should= be
> removed
>
> assign_operator : '=3D'=C2=A0=C2=A0 /* not documented because = it might be removed someday *

Comment updated. =C2=A0Patch attached.

<= br>
Still I am missing message about preferred syntax (or we shou= ld to enhance 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 synta= x (and ADA in simplified ADA syntax)

We have to find a ag= reement what we will prefer for PL/pgSQL:

The assign statement is "ADA" statement - ":= =3D" is preferred

The GET DIAGNOSTICS is "SQL&= quot; statement - "=3D" is preferred

A newer SQ= L/PSM was designed differently - without this dichotomy - A assignment is e= mphased by syntax SET varname =3D value
=C2=A0
A proper syntax is good information what is= coming from - and It is good mental helper to understand a philosophy of s= tored procedures (that shares concepts with PL/SQL). Next argument is simil= arity with PL/SQL and SQL PL. This statement (GET DIAGNOSTICS) is supported= on both environments and only "=3D" is allowed there.

Regards

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. +

--001a11c3e56660a20d04efbfaeea--