Subject: remove undocumented assign syntax from plpgsql doc

From: Pavel Stehule <[email-masked]>
Date: Wed, 29 May 2013 10:02:20 +0200

Hello

remove undocumented syntax for assign statements in plpgsql doc examples

related to http://www.postgresql.org/message-id/CAJ4CxLkBFNAAsWdz=CsDkU1nC0De60WO15de=[email-masked]
thread

Regards

Pavel Stehule

-- 
Sent via pgsql-docs mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 11 Jan 2014 13:41:06 -0500

Applied.

---------------------------------------------------------------------------

> diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
> index 19498c6..1817c9d 100644
> --- a/doc/src/sgml/plpgsql.sgml
> +++ b/doc/src/sgml/plpgsql.sgml
> @@ -3815,20 +3815,20 @@ CREATE OR REPLACE FUNCTION update_emp_view() RETURNS TRIGGER AS $$
>              DELETE FROM emp WHERE empname = OLD.empname;
>              IF NOT FOUND THEN RETURN NULL; END IF;
>  
> -            OLD.last_updated = now();
> +            OLD.last_updated := now();
>              INSERT INTO emp_audit VALUES('D', user, OLD.*);
>              RETURN OLD;
>          ELSIF (TG_OP = 'UPDATE') THEN
>              UPDATE emp SET salary = NEW.salary WHERE empname = OLD.empname;
>              IF NOT FOUND THEN RETURN NULL; END IF;
>  
> -            NEW.last_updated = now();
> +            NEW.last_updated := now();
>              INSERT INTO emp_audit VALUES('U', user, NEW.*);
>              RETURN NEW;
>          ELSIF (TG_OP = 'INSERT') THEN
>              INSERT INTO emp VALUES(NEW.empname, NEW.salary);
>  
> -            NEW.last_updated = now();
> +            NEW.last_updated := now();
>              INSERT INTO emp_audit VALUES('I', user, NEW.*);
>              RETURN NEW;
>          END IF;
> @@ -3913,10 +3913,10 @@ AS $maint_sales_summary_bytime$
>          -- Work out the increment/decrement amount(s).
>          IF (TG_OP = 'DELETE') THEN
>  
> -            delta_time_key = OLD.time_key;
> -            delta_amount_sold = -1 * OLD.amount_sold;
> -            delta_units_sold = -1 * OLD.units_sold;
> -            delta_amount_cost = -1 * OLD.amount_cost;
> +            delta_time_key := OLD.time_key;
> +            delta_amount_sold := -1 * OLD.amount_sold;
> +            delta_units_sold := -1 * OLD.units_sold;
> +            delta_amount_cost := -1 * OLD.amount_cost;
>  
>          ELSIF (TG_OP = 'UPDATE') THEN
>  
> @@ -3928,17 +3928,17 @@ AS $maint_sales_summary_bytime$
>                                                        OLD.time_key, NEW.time_key;
>              END IF;
>  
> -            delta_time_key = OLD.time_key;
> -            delta_amount_sold = NEW.amount_sold - OLD.amount_sold;
> -            delta_units_sold = NEW.units_sold - OLD.units_sold;
> -            delta_amount_cost = NEW.amount_cost - OLD.amount_cost;
> +            delta_time_key := OLD.time_key;
> +            delta_amount_sold := NEW.amount_sold - OLD.amount_sold;
> +            delta_units_sold := NEW.units_sold - OLD.units_sold;
> +            delta_amount_cost := NEW.amount_cost - OLD.amount_cost;
>  
>          ELSIF (TG_OP = 'INSERT') THEN
>  
> -            delta_time_key = NEW.time_key;
> -            delta_amount_sold = NEW.amount_sold;
> -            delta_units_sold = NEW.units_sold;
> -            delta_amount_cost = NEW.amount_cost;
> +            delta_time_key := NEW.time_key;
> +            delta_amount_sold := NEW.amount_sold;
> +            delta_units_sold := NEW.units_sold;
> +            delta_amount_cost := NEW.amount_cost;
>  
>          END IF;
>  

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

---

From: Tom Lane <[email-masked]>
Date: Sat, 11 Jan 2014 13:52:30 -0500

> Applied.

I thought the consensus in the referenced thread had been to go the other
way.  We're not going to remove the syntax option to use "=", so shouldn't
we document it rather than pretending it doesn't exist?

The end of the other thread was
http://www.postgresql.org/message-id/[email-masked]

			regards, tom lane

---

From: Pavel Stehule <[email-masked]>
Date: Sat, 11 Jan 2014 20:00:55 +0100

is not better to be consistent in doc?

Im not aganst to documentation second syntax, but examples in doc should be
consistent

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 11 Jan 2014 14:02:46 -0500

> http://www.postgresql.org/message-id/[email-masked]

Oh, I think you are right.  I have reverted the patch.  Attached is
proposed documentation for '='.

  + Everyone has their own god. +
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
new file mode 100644
index ca2c2b5..6c83789
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*************** arow RECORD;
*** 328,334 ****
      <para>
       The general syntax of a variable declaration is:
  <synopsis>
! <replaceable>name</replaceable> <optional> CONSTANT </optional> <replaceable>type</replaceable> <optional> COLLATE <replaceable>collation_name</replaceable> </optional> <optional> NOT NULL </optional> <optional> { DEFAULT | := } <replaceable>expression</replaceable> </optional>;
  </synopsis>
        The <literal>DEFAULT</> clause, if given, specifies the initial value assigned
        to the variable when the block is entered.  If the <literal>DEFAULT</> clause
--- 328,334 ----
      <para>
       The general syntax of a variable declaration is:
  <synopsis>
! <replaceable>name</replaceable> <optional> CONSTANT </optional> <replaceable>type</replaceable> <optional> COLLATE <replaceable>collation_name</replaceable> </optional> <optional> NOT NULL </optional> <optional> { DEFAULT | := | = } <replaceable>expression</replaceable> </optional>;
  </synopsis>
        The <literal>DEFAULT</> clause, if given, specifies the initial value assigned
        to the variable when the block is entered.  If the <literal>DEFAULT</> clause

---

From: Tom Lane <[email-masked]>
Date: Sat, 11 Jan 2014 14:12:49 -0500

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

I'd be a bit inclined to just stick a NOTE somewhere saying that "="
can be used in place of ":=" for assignment.

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 11 Jan 2014 14:39:07 -0500

> can be used in place of ":=" for assignment.

OK, here is an updated doc patch that does that.  The next question is
whether we want examples using '=' instead of ':='?  Right now we have
them, and Pavel's patch removed them.

  + Everyone has their own god. +
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
new file mode 100644
index ca2c2b5..4cf9be9
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*************** arow RECORD;
*** 343,348 ****
--- 343,349 ----
        is specified, an assignment of a null value results in a run-time
        error. All variables declared as <literal>NOT NULL</>
        must have a nonnull default value specified.
+       Equals (<literal>=</>) can be used instead of <literal>:=</>.
       </para>
  
       <para>

---

From: Tom Lane <[email-masked]>
Date: Sat, 11 Jan 2014 14:46:58 -0500

Bruce Momjian <[email-masked]> writes:
> OK, here is an updated doc patch that does that.

You're still only touching the variable-initialization case, which seems
like the least important place to document it.  I'd have put it with
the assignment-statement documentation.  Perhaps something like

    <note>
     <para>
      Here, and in other contexts such as variable initialization,
      the assignment operator can be written <literal>=</> as well
      as <literal>:=</>.  The latter is the preferred spelling, though.
     </para>
    </note>

> The next question is

AFAIR, we have some of both, and I'm fine with that status quo.

			regards, tom lane

---

From: Pavel Stehule <[email-masked]>
Date: Sat, 11 Jan 2014 22:06:27 +0100

2014/1/11 Tom Lane <[email-masked]>

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

Same situation is with UPDATE statement - we don't allow ":=" there.

> 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 */
                                | COLON_EQUALS
                                ;

Regards

Pavel

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 11 Jan 2014 23:23:06 -0500

On Sat, Jan 11, 2014 at 10:06:27PM +0100, Pavel Stehule wrote:
> 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?

> assign_operator : '='   /* not documented because it might be removed someday *

Comment updated.  Patch attached.

index ca2c2b5..da1d35c
  
       <para>
*************** PREPARE <replaceable>statement_name</>(i
*** 866,872 ****
       An assignment of a value to a <application>PL/pgSQL</application>
       variable is written as:
  <synopsis>
! <replaceable>variable</replaceable> := <replaceable>expression</replaceable>;
  </synopsis>
       As explained previously, the expression in such a statement is evaluated
       by means of an SQL <command>SELECT</> command sent to the main
--- 867,873 ----
       An assignment of a value to a <application>PL/pgSQL</application>
       variable is written as:
  <synopsis>
! <replaceable>variable</replaceable> { := | = } <replaceable>expression</replaceable>;
  </synopsis>
       As explained previously, the expression in such a statement is evaluated
       by means of an SQL <command>SELECT</> command sent to the main
*************** PREPARE <replaceable>statement_name</>(i
*** 874,880 ****
       a row value, if the variable is a row or record variable).  The target
       variable can be a simple variable (optionally qualified with a block
       name), a field of a row or record variable, or an element of an array
!      that is a simple variable or field.
      </para>
  
      <para>
--- 875,882 ----
       a row value, if the variable is a row or record variable).  The target
       variable can be a simple variable (optionally qualified with a block
       name), a field of a row or record variable, or an element of an array
!      that is a simple variable or field.  Equals (<literal>=</>) can be
!      used instead of <literal>:=</>.
      </para>
  
      <para>
*************** EXECUTE format('UPDATE tbl SET %I = $1 W
*** 1411,1417 ****
       command, which has the form:
  
  <synopsis>
! GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replaceable> <optional> , ... </optional>;
  </synopsis>
  
       This command allows retrieval of system status indicators.  Each
--- 1413,1419 ----
       command, which has the form:
  
  <synopsis>
! GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> { = | := } <replaceable>item</replaceable> <optional> , ... </optional>;
  </synopsis>
  
       This command allows retrieval of system status indicators.  Each
*************** SELECT merge_db(1, 'dennis');
*** 2672,2678 ****
       <command>GET STACKED DIAGNOSTICS</command> command, which has the form:
  
  <synopsis>
! GET STACKED DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replaceable> <optional> , ... </optional>;
  </synopsis>
  
       Each <replaceable>item</replaceable> is a key word identifying a status
--- 2674,2680 ----
       <command>GET STACKED DIAGNOSTICS</command> command, which has the form:
  
  <synopsis>
! GET STACKED DIAGNOSTICS <replaceable>variable</replaceable> { = | := } <replaceable>item</replaceable> <optional> , ... </optional>;
  </synopsis>
  
       Each <replaceable>item</replaceable> is a key word identifying a status
*************** END;
*** 2776,2782 ****
     <para>
  
  <synopsis>
! GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>PG_CONTEXT</replaceable> <optional> , ... </optional>;
  </synopsis>

--- 2778,2784 ----
     <para>
  
  <synopsis>
! GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> { = | := } <replaceable>PG_CONTEXT</replaceable> <optional> , ... </optional>;
  </synopsis>

*************** OPEN curs1 FOR EXECUTE 'SELECT * FROM '
*** 2980,2986 ****
       <title>Opening a Bound Cursor</title>
  
  <synopsis>
! OPEN <replaceable>bound_cursorvar</replaceable> <optional> ( <optional> <replaceable>argument_name</replaceable> := </optional> <replaceable>argument_value</replaceable> <optional>, ...</optional> ) </optional>;
  </synopsis>
  
           <para>
--- 2982,2988 ----
       <title>Opening a Bound Cursor</title>
  
  <synopsis>
! OPEN <replaceable>bound_cursorvar</replaceable> <optional> ( <optional> <replaceable>argument_name</replaceable> { := | = } </optional> <replaceable>argument_value</replaceable> <optional>, ...</optional> ) </optional>;
  </synopsis>
  
           <para>
*************** COMMIT;
*** 3333,3339 ****
  
  <synopsis>
  <optional> &lt;&lt;<replaceable>label</replaceable>&gt;&gt; </optional>
! FOR <replaceable>recordvar</replaceable> IN <replaceable>bound_cursorvar</replaceable> <optional> ( <optional> <replaceable>argument_name</replaceable> := </optional> <replaceable>argument_value</replaceable> <optional>, ...</optional> ) </optional> LOOP
      <replaceable>statements</replaceable>
  END LOOP <optional> <replaceable>label</replaceable> </optional>;
  </synopsis>
--- 3335,3341 ----
  
  <synopsis>
  <optional> &lt;&lt;<replaceable>label</replaceable>&gt;&gt; </optional>
! FOR <replaceable>recordvar</replaceable> IN <replaceable>bound_cursorvar</replaceable> <optional> ( <optional> <replaceable>argument_name</replaceable> { := | = } </optional> <replaceable>argument_value</replaceable> <optional>, ...</optional> ) </optional> LOOP
      <replaceable>statements</replaceable>
  END LOOP <optional> <replaceable>label</replaceable> </optional>;
  </synopsis>
diff --git a/src/pl/plpgsql/src/pl_gram.y b/src/pl/plpgsql/src/pl_gram.y
new file mode 100644
index 3fd6655..03a132d
*** a/src/pl/plpgsql/src/pl_gram.y
--- b/src/pl/plpgsql/src/pl_gram.y
*************** decl_defkey		: assign_operator
*** 796,802 ****
  				| K_DEFAULT
  				;
  
! assign_operator	: '='	/* not documented because it might be removed someday */
  				| COLON_EQUALS
  				;
  
--- 796,802 ----
  				| K_DEFAULT
  				;
  
! assign_operator	: '='	/* alternative to := */
  				| COLON_EQUALS
  				;

---

From: Pavel Stehule <[email-masked]>
Date: Sun, 12 Jan 2014 06:38:04 +0100

2014/1/12 Bruce Momjian <[email-masked]>

> only -

no, there are not used assign_operator

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

> someday *

---

From: Pavel Stehule <[email-masked]>
Date: Sun, 12 Jan 2014 07:00:09 +0100

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 12 Jan 2014 21:48:46 -0500

On Sun, Jan 12, 2014 at 06:38:04AM +0100, Pavel Stehule wrote:
>     >     > Oh, I think you are right.  I have reverted the patch.  Attached is
>     >     > proposed documentation for '='.
>     >

OK, patch updated and attached.

index ca2c2b5..151fcb9
  
       <para>
  
      <para>
--- 875,882 ----
  
      <para>
  
  <synopsis>

  <synopsis>

  <synopsis>

  <synopsis>

  <synopsis>

--- 2778,2784 ----
     <para>
  
  <synopsis>

  
--- 796,802 ----
  				| K_DEFAULT
  				;

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 12 Jan 2014 21:59:04 -0500

On Sun, Jan 12, 2014 at 07:00:09AM +0100, Pavel Stehule wrote:
> Still I am missing message about preferred syntax (or we should to enhance GET
> DIAGNOSTICS doc about proprietary syntax).
> 
> decided so embedded SQL statements will be placed in native SQL syntax (and ADA
> in simplified ADA syntax)
> 
> 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.

---

From: Pavel Stehule <[email-masked]>
Date: Mon, 13 Jan 2014 06:10:24 +0100

2014/1/13 Bruce Momjian <[email-masked]>

> mental

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

Pavel

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 13 Jan 2014 09:04:33 -0500

On Mon, Jan 13, 2014 at 06:10:24AM +0100, Pavel Stehule wrote:
> just a note about preferred variant should be ok. Using ':=' in GET DIAGNOSTICS
> statement is just bad idea.

Agreed.  I added a sentence in the first mention of GET DIAGNOSTICS, and
indicated it was generic for that command.  What I also added was your
description of when to use := and =, but I put it in the C comments so
we have a record of it and if we need to expand the description or
behavior later. 

index ca2c2b5..b937580
  
       <para>
  
      <para>
--- 875,882 ----
  
      <para>
  
  <synopsis>

  <synopsis>
  
       This command allows retrieval of system status indicators.  Each
*************** GET <optional> CURRENT </optional> DIAGN
*** 1425,1430 ****
--- 1427,1434 ----
       <acronym>SQL</acronym> command.  Note that <varname>RESULT_OID</>
       is only useful after an <command>INSERT</command> command into a
       table containing OIDs.
+      Equals (<literal>:=</>) can be used instead of <literal>=</> for
+      <command>GET DIAGNOSTICS</>.
      </para>
  
      <para>
  
  <synopsis>
  
--- 2676,2682 ----
  
  <synopsis>

  <synopsis>

--- 2780,2786 ----
     <para>
  
  <synopsis>

index 3fd6655..9284cf3

--- 796,807 ----
  				| K_DEFAULT
  				;
  
! /*
!  * Ada-based PL/SQL uses := for assignment and variable defaults, while
!  * standards-based PSM uses equals for these cases and for GET DIAGNOSTICS,
!  * so we support both.  FOR and OPEN only support :=.
!  */
! assign_operator	: '='
  				| COLON_EQUALS
  				;

---

From: Pavel Stehule <[email-masked]>
Date: Mon, 13 Jan 2014 15:36:18 +0100

> we have a record of it and if we need to expand the description or

I'll be more happy if a comment about GET DIAGNOSTICS statement will be in
user space.

Regards

Pavel

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 Jan 2014 15:21:28 -0500

On Mon, Jan 13, 2014 at 03:36:18PM +0100, Pavel Stehule wrote:
> I'll be more happy if a comment about GET DIAGNOSTICS statement will be in user
> space.

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.

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 15 Jan 2014 11:07:29 +0100

2014/1/14 Bruce Momjian <[email-masked]>

> section Porting from Oracle PL/SQL, and I don't see how it fits there
:)

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

Regards

Pavel

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 15 Jan 2014 10:35:35 -0500

On Wed, Jan 15, 2014 at 11:07:29AM +0100, Pavel Stehule wrote:
> Using ":=" is preffered as assign statement due conformity with ADA language (a
> plpgsql ancestor).
> 
> 
> ==GET DIAGNOSTICS==
> 

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?

index ca2c2b5..0ca9458
--- 343,350 ----
+       Equals (<literal>=</>) can be used instead of PL/SQL-compliant
+       <literal>:=</>.
       </para>
  
       <para>
--- 868,874 ----
  
      <para>
--- 876,883 ----
!      used instead of PL/SQL-compliant <literal>:=</>.
      </para>
  
      <para>
  
  <synopsis>
  
--- 1414,1420 ----
  
  <synopsis>
  
       This command allows retrieval of system status indicators.  Each
*************** GET <optional> CURRENT </optional> DIAGN
*** 1425,1430 ****
--- 1428,1435 ----
       <acronym>SQL</acronym> command.  Note that <varname>RESULT_OID</>
       is only useful after an <command>INSERT</command> command into a
       table containing OIDs.
+      Equals (<literal>:=</>) can be used instead of SQL/PSM-compliant
+      <literal>=</> for <command>GET DIAGNOSTICS</>.
      </para>
  
      <para>
  
  <synopsis>
  
--- 2677,2683 ----
  
  <synopsis>

  <synopsis>

--- 2781,2787 ----
     <para>
  
  <synopsis>

index 3fd6655..55c8e25

--- 796,807 ----
  				| K_DEFAULT
  				;
  
! /*
!  * Ada-based PL/SQL uses := for assignment and variable defaults, while
!  * standards-based SQL/PSM uses equals for these cases and for GET
!  * DIAGNOSTICS, so we support both.  FOR and OPEN only support :=.
!  */
! assign_operator	: '='
  				| COLON_EQUALS
  				;

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 15 Jan 2014 16:55:11 +0100

2014/1/15 Bruce Momjian <[email-masked]>

> Is GET DIAGNOSTICS defined in the standard for SQL/PSM only or for
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"

Regards

Pavel

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 15 Jan 2014 17:00:53 +0100

2014/1/15 Pavel Stehule <[email-masked]>

> in generic SQL - today "SQL framework" part and it is enhanced in "SQL/PSM"

sorry s/SQL framework/SQL Foundation/

Regards

Pavel

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 15 Jan 2014 11:32:59 -0500

On Wed, Jan 15, 2014 at 04:55:11PM +0100, Pavel Stehule wrote:
> 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"

OK, patch updated.

index ca2c2b5..48880ce
  
       <para>
  
      <para>
--- 876,883 ----
  
      <para>
  
  <synopsis>

  <synopsis>
  
+      Equals (<literal>:=</>) can be used instead of SQL-standard
  
      <para>
  
  <synopsis>

  <synopsis>

  <synopsis>

--- 2781,2787 ----
     <para>
  
  <synopsis>

index 3fd6655..c0cb585

--- 796,807 ----
  				| K_DEFAULT
  				;
  
! /*
!  * Ada-based PL/SQL uses := for assignment and variable defaults, while
!  * the SQL standard uses equals for these cases and for GET
!  * DIAGNOSTICS, so we support both.  FOR and OPEN only support :=.
!  */
! assign_operator	: '='
  				| COLON_EQUALS
  				;

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 15 Jan 2014 17:39:22 +0100

ok

I don't understand last sentence of comment

 ! /*

"FOR and OPEN only support :="

FOR statement nor OPEN statement doesn't use ":="

Regards

Pavel

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 15 Jan 2014 15:36:04 -0500

> FOR statement nor OPEN statement doesn't use ":="

Uh, I see it in the documented syntax:

	OPEN <replaceable>bound_cursorvar</replaceable> <optional> ( <optional>
	<replaceable>argument_name</replaceable> := </optional>  <---
	<replaceable>argument_value
	
	FOR <replaceable>recordvar</replaceable> IN
	<replaceable>bound_cursorvar</replaceable> <optional> ( <optional>
	<replaceable>argument_name</replaceable> :=   <---
	</optional> <replaceable>argument_value

---

From: Tom Lane <[email-masked]>
Date: Wed, 15 Jan 2014 15:47:13 -0500

> 	<replaceable>argument_value

It is there, if you look into read_cursor_args().

This appears to be the only place in pl_gram.y where we don't treat '='
and COLON_EQUALS interchangeably.

I was about to suggest that we should accept "=" here too, but on second
thought that could break existing code, if anyone's using boolean equality
expressions in cursor arguments.  So we'd better accept the inconsistency.

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 16 Jan 2014 16:40:36 -0500

> > generic SQL - today "SQL framework" part and it is enhanced in "SQL/PSM"

Patch applied.  Yeah!