Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Dl4-00054i-Tm for pgsql-docs@arkaria.postgresql.org; Sun, 12 Jan 2014 05:38:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W2Dl4-0007Vz-DI for pgsql-docs@arkaria.postgresql.org; Sun, 12 Jan 2014 05:38:50 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Dl3-0007Vs-AI for pgsql-docs@postgresql.org; Sun, 12 Jan 2014 05:38:49 +0000 Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Dl0-0005uE-JE for pgsql-docs@postgresql.org; Sun, 12 Jan 2014 05:38:48 +0000 Received: by mail-ee0-f50.google.com with SMTP id d17so108163eek.23 for ; Sat, 11 Jan 2014 21:38:45 -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=7zMSwJQJPLvMoun0vp6vQBQIDtEtN+Koc+VfkR1yWEw=; b=X2RE5aZSXw1oD092uSKJzhBgptu+HM6HetCbSWgDYTWLASG8uZXgEoXZpRuIq8XVYb YSYAOAPNpFPg0yo8ZVeukPFvAfpyilKoa+irn3E7WyHCUMOB3h4D0YiDKnIWktbh/SEe c3O4u56UHhJH32abc8wro+Pt1dqf2EGt/WeJK9MIwPtut6sNRF3wLOVdZPmG9hd522+q EYjMd8QU/qXsalVrs5rRVRVmRNqMaVaZNKD7r++0flQnAUpMikvcGBEeXD0mOPT3MuCZ pRzN/+ubOzOzAJv2JDLVcs227TuJ4DGhCm+DKEboUuMIJl7QSyqLA/7szWwPY+qIKhOz b5Vw== X-Received: by 10.14.6.5 with SMTP id 5mr19163814eem.51.1389505124101; Sat, 11 Jan 2014 21:38:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.75.198 with HTTP; Sat, 11 Jan 2014 21:38:04 -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 06:38:04 +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=089e01681a2055f13704efbf5f96 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 --089e01681a2055f13704efbf5f96 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? > no, there are not used assign_operator It is used only in DECLARE DEFAULT, ASSIGN and GET DIAGNOSTICS > > > 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. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + Everyone has their own god. + > --089e01681a2055f13704efbf5f96 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?

no, there are not used assign_op= erator

It is used only in DECLARE DEFAULT, ASSIGN and GET= DIAGNOSTICS
=C2=A0

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

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

--089e01681a2055f13704efbf5f96--