Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W3SuW-00023t-OD for pgsql-docs@arkaria.postgresql.org; Wed, 15 Jan 2014 16:01:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W3SuW-0004YS-8H for pgsql-docs@arkaria.postgresql.org; Wed, 15 Jan 2014 16:01:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W3SuV-0004YM-Ki for pgsql-docs@postgresql.org; Wed, 15 Jan 2014 16:01:43 +0000 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W3SuS-0007jX-Ap for pgsql-docs@postgresql.org; Wed, 15 Jan 2014 16:01:43 +0000 Received: by mail-ea0-f180.google.com with SMTP id f15so569547eak.39 for ; Wed, 15 Jan 2014 08:01:36 -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=gsq8O5Lu1djsXBVzgLeFIqv1J7d4o0TTWIOll2QIH6Y=; b=fC+xkWHBGEalk0cZpAWGONMjnL9yaCfIUhpVqzatx9A3Jw+mj33cpEvczQRpMR7WL8 ReKYn9/vFOj3a11ZtMaZ5ZFEr/dNLrn8CugdpGEyYBv2r8f3T6kSNQ6TSpHpdSu0qZ+9 vSNT4p2QeYEWqnd0wMXYQMbnqt2XigmHOuAM5+EeTo+H13Ftqd7LJxZD78Bzk+CIsXVR +GDKQdFS5mOSODGtcooQuJjDGnOe8aX25ex55D3+MuLmq6EUg4Ko3OTB9Xp5mg6/cRVT a9dB/vZP9G34wPUFcSJn1wKEvZuUyGIcOpI9DusXitPlefCoXYsQEuQrUnykb7gI7Ypi rqiA== X-Received: by 10.14.6.5 with SMTP id 5mr4603856eem.51.1389801693918; Wed, 15 Jan 2014 08:01:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.75.198 with HTTP; Wed, 15 Jan 2014 08:00:53 -0800 (PST) In-Reply-To: References: <24577.1389467569@sss.pgh.pa.us> <20140112042306.GM28089@momjian.us> <20140113025904.GB22464@momjian.us> <20140113140433.GA7868@momjian.us> <20140114202128.GA7761@momjian.us> <20140115153535.GA7607@momjian.us> From: Pavel Stehule Date: Wed, 15 Jan 2014 17:00:53 +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=089e01681a20463a4b04f0046c24 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 --089e01681a20463a4b04f0046c24 Content-Type: text/plain; charset=UTF-8 2014/1/15 Pavel Stehule > > > > 2014/1/15 Bruce Momjian > >> On Wed, Jan 15, 2014 at 11:07:29AM +0100, Pavel Stehule wrote: >> > I thought you would say that. :-) I don't see how this detail >> makes >> > sense in the sections related to the syntax usage, so I looked in >> the >> > section Porting from Oracle PL/SQL, and I don't see how it fits >> there >> > either. >> > >> > >> > >> > :) >> > >> > just notice - sorry for my English >> > >> > ==Assign== >> > Using ":=" is preffered as assign statement due conformity with ADA >> language (a >> > plpgsql ancestor). >> > >> > >> > ==GET DIAGNOSTICS== >> > >> > Using "=" is highly preferred due conformity with ANSI/SQL >> >> The problem is that these are philosophical issues that are not normally >> covered in our docs. What I have done is to add a mention of which >> option is compliant to the new text. Patch attached. >> >> Is GET DIAGNOSTICS defined in the standard for SQL/PSM only or for >> generic SQL? >> >> > I found this statement in ANSI SQL 92 - and few minutes searching - it is > in generic SQL - today "SQL framework" part and it is enhanced in "SQL/PSM" > sorry s/SQL framework/SQL Foundation/ Regards Pavel > > Regards > > Pavel > > >> -- >> Bruce Momjian http://momjian.us >> EnterpriseDB http://enterprisedb.com >> >> + Everyone has their own god. + >> > > --089e01681a20463a4b04f0046c24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



2014/1/15 Pavel Stehule <pavel.stehule@gmail.com>



2014/1/15 Bruce Momjian <bruce@momjian.us>=
On Wed, Jan 15, 2014 at 11:07:29AM +0100, Pavel Stehule wrote:
> =C2=A0 =C2=A0 I thought you would say that. =C2=A0:-) =C2=A0I don'= t see how this detail makes
> =C2=A0 =C2=A0 sense in the sections related to the syntax usage, so I = looked in the
> =C2=A0 =C2=A0 section Porting from Oracle PL/SQL, and I don't see = how it fits there
> =C2=A0 =C2=A0 either.
>
>
>
> :)
>
> just notice - sorry for my English
>
> =3D=3DAssign=3D=3D
> Using ":=3D" is preffered as assign statement due conformity= with ADA language (a
> plpgsql ancestor).
>
>
> =3D=3DGET DIAGNOSTICS=3D=3D
>
> Using "=3D" is highly preferred due conformity with ANSI/SQL=

The problem is that these are philosophical issues that are not norma= lly
covered in our docs. =C2=A0What I have done is to add a mention of which option is compliant to the new text. =C2=A0Patch attached.

Is GET DIAGNOSTICS defined in the standard for SQL/PSM only or for
generic SQL?


I found th= is statement in ANSI SQL 92 - and few minutes searching - it is in generic = SQL - today "SQL framework" part and it is enhanced in "SQL/= PSM"

sorry s/SQL framew= ork/SQL Foundation/

Regards

Pavel
=C2=A0

Regards
Pavel
=C2=A0
--
=C2=A0 Bruce Momjian =C2=A0<bruce@momjian.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. +


--089e01681a20463a4b04f0046c24--