Re: [HACKERS] pl/pgsql: END verbosity [patch]

[Neil Conway]

Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label 
has only informational value, but can enhance readability large block and 
enhance likeness with Oracle.


Reviewed and applied -- thanks for the patch.

-Neil

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] pl/pgsql: END verbosity [patch]

[Neil Conway]

Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label 
has only informational value, but can enhance readability large block and 
enhance likeness with Oracle.


<>LOOP
 ...
 ...
END LOOP<>;


Attached is a revised version of this patch. Changes / comments:

- AFAICS Oracle's syntax is actually

<> LOOP
...
END LOOP label;

i.e. the ending block label isn't enclosed in <<>>. I've adjusted the 
patch accordingly.


- your patch broke EXIT and CONTINUE, as running the regression tests 
would have made clear.


- yyerror() will set plpgsql_error_lineno, so you needn't do it 
yourself. I changed it to use ereport(ERROR) anyway, as it seems a bit 
more appropriate. I'm not quite happy with the error message text:


ERROR:  end label "outer_label" differs from block's label "inner_label"
CONTEXT:  compile of PL/pgSQL function "end_label3" near line 6

ERROR:  end label "outer_label" specified for unlabelled block
CONTEXT:  compile of PL/pgSQL function "end_label4" near line 5

suggestions for improvement are welcome.

BTW, I notice that some but not all the call sites of ereport(ERROR) in 
PL/PgSQL's gram.y set plpgsql_error_lineno. Is there a reason for this?


Barring any objections, I'll apply the attached patch to CVS tomorrow.

-Neil
Index: doc/src/sgml/plpgsql.sgml
===
RCS file: /Users/neilc/local/cvs/pgsql/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.74
diff -c -r1.74 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml   22 Jun 2005 01:35:02 -  1.74
--- doc/src/sgml/plpgsql.sgml   1 Jul 2005 11:43:36 -
***
*** 456,462 
  declarations 
  BEGIN
  statements
! END;
  
  
  
--- 456,462 
  declarations 
  BEGIN
  statements
! END  label ;
  
  
  
***
*** 1789,1806 
   LOOP
  
  
! <>
  LOOP
  statements
! END LOOP;
  
  
   
!   LOOP defines an unconditional loop that is repeated 
indefinitely
!   until terminated by an EXIT or RETURN
!   statement.  The optional label can be used by EXIT 
statements in
!   nested loops to specify which level of nesting should be
!   terminated.
   
  
  
--- 1789,1807 
   LOOP
  
  
!  <> 
  LOOP
  statements
! END LOOP  label ;
  
  
   
!   LOOP defines an unconditional loop that is repeated
!   indefinitely until terminated by an EXIT or
!   RETURN statement.  The optional
!   label can be used by EXIT
!   and CONTINUE statements in nested loops to
!   specify which loop the statement should be applied to.
   
  
  
***
*** 1920,1929 
   
  
  
! <>
  WHILE expression LOOP
  statements
! END LOOP;
  
  
 
--- 1921,1930 
   
  
  
!  <> 
  WHILE expression LOOP
  statements
! END LOOP  label ;
  
  
 
***
*** 1951,1960 
FOR (integer variant)
  
  
! <>
  FOR name IN  REVERSE  
expression .. expression 
LOOP
  statements
! END LOOP;
  
  
 
--- 1952,1961 
FOR (integer variant)
  
  
!  <> 
  FOR name IN  REVERSE  
expression .. expression 
LOOP
  statements
! END LOOP  labal ;
  
  
 
***
*** 1997,2006 
   the results of a query and manipulate that data
   accordingly. The syntax is:
  
! <>
  FOR record_or_row IN 
query LOOP
  statements
! END LOOP;
  
   The record or row variable is successively assigned each row
   resulting from the query (which must be a
--- 1998,2007 
   the results of a query and manipulate that data
   accordingly. The syntax is:
  
!  <> 
  FOR record_or_row IN 
query LOOP
  statements
! END LOOP  label ;
  
   The record or row variable is successively assigned each row
   resulting from the query (which must be a
***
*** 2036,2045 
   The FOR-IN-EXECUTE statement is another way to iterate over
   rows:
  
! <>
  FOR record_or_row IN EXECUTE 
text_expression LOOP 
  statements
! END LOOP;
  
   This is like the previous form, except that the source
   SELECT statement is specified as a string
--- 2037,2046 
   The FOR-IN-EXECUTE statement is another way to iterate over
   rows:
  
!  <> 
  FOR record_or_row IN EXECUTE 
text_expression LOOP 
  statements
! END LOOP  label ;
  
   This is like the previous form, except that the source
   SELECT statement is specified as a string
Index: src/pl/plpgsql/src/gram.y
===
RCS file: /Users/neilc/local/cvs/pgsql/src/pl/plpgsql/src/gram.y,v
retrieving revision 1.77
diff -c -r1.77 gram.y
*** src/pl/plpgsql/src/gram.y   22 Jun 2005 01:35:02 -  1.77
--- src/pl/plpgsql/src/gram.y   1 Jul 2005 12:08:45 -
***
*** 56,61 
--- 56,63 
  

Re: [HACKERS] pl/pgsql: END verbosity

[Pavel Stehule]

On Mon, 27 Jun 2005, Neil Conway wrote:

> Peter Eisentraut wrote:
> > It is required by the SQL standard.
> 
> No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess 
> you're referring to SQL/PSM, but that has only a passing resemblance to 
> PL/PgSQL. Implementing SQL/PSM in some form would definitely be worth 
> doing (especially now that MySQL have), but I haven't seen any plans to 
> do that by adapting PL/PgSQL to SQL/PSM.

PL/pgSQL is different language than SQL/PSM and is little bit nonsenc 
adapting them to SQL/PSM. PL/SQL live still - Oracle did some enhancing, 
and we can do it too. 

Some parts both languages are similar and some enough different. I had 
plan start develop new interpret for SQL/PSM two years ago, but I hadn't 
knowleages at that time. Situation is different now. If anybody wont to 
work on SQL/PSM  I will go too. Solution is another pl - pl/psm. We can 
adapt gram.y plpgsql to psm

Regards
Pavel Stehule



---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] pl/pgsql: END verbosity

[Peter Eisentraut]

Neil Conway wrote:
> No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess
> you're referring to SQL/PSM, but that has only a passing resemblance
> to PL/PgSQL. Implementing SQL/PSM in some form would definitely be
> worth doing (especially now that MySQL have), but I haven't seen any
> plans to do that by adapting PL/PgSQL to SQL/PSM.

I don't claim to recall the details, but we have frequently referred to 
the SQL standard when resolving issues about PL/pgSQL's syntax.

> In any case, there are plenty of cases in which we accept a superset
> of the syntax defined by the SQL standard -- DROP TABLE { RESTRICT |
> CASCADE }, for example. We have never interpreted compliance with the
> SQL specification to mean that we must *only* accept the standard's
> syntax and nothing else.

The cases were we accept a superset of the SQL standard are either 
additional features, backward compatibility, or compatibility to other 
systems -- none of which seem to apply here.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] pl/pgsql: END verbosity

[Neil Conway]

Peter Eisentraut wrote:

It is required by the SQL standard.


No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess 
you're referring to SQL/PSM, but that has only a passing resemblance to 
PL/PgSQL. Implementing SQL/PSM in some form would definitely be worth 
doing (especially now that MySQL have), but I haven't seen any plans to 
do that by adapting PL/PgSQL to SQL/PSM.


In any case, there are plenty of cases in which we accept a superset of 
the syntax defined by the SQL standard -- DROP TABLE { RESTRICT | 
CASCADE }, for example. We have never interpreted compliance with the 
SQL specification to mean that we must *only* accept the standard's 
syntax and nothing else.


-Neil

---(end of broadcast)---
TIP 6: Have you searched our list archives?

  http://archives.postgresql.org

[HACKERS] pl/pgsql: END verbosity [patch]

[Pavel Stehule]

Hello

this patch allows optional using label with END and END LOOP. Ending label 
has only informational value, but can enhance readability large block and 
enhance likeness with Oracle.

<>LOOP
 ...
 ...
END LOOP<>;

Regards
Pavel Stehule
diff -c -r --new-file pgsql/doc/src/sgml/plpgsql.sgml 
pgsql.01/doc/src/sgml/plpgsql.sgml
*** pgsql/doc/src/sgml/plpgsql.sgml 2005-06-24 13:10:33.0 +0200
--- pgsql.01/doc/src/sgml/plpgsql.sgml  2005-06-25 15:29:27.0 +0200
***
*** 456,462 
  declarations 
  BEGIN
  statements
! END;
  
  
  
--- 456,462 
  declarations 
  BEGIN
  statements
! END  <> ;
  
  
  
***
*** 1792,1798 
  <>
  LOOP
  statements
! END LOOP;
  
  
   
--- 1792,1798 
  <>
  LOOP
  statements
! END LOOP 
<>;
  
  
   
***
*** 1923,1929 
  <>
  WHILE expression LOOP
  statements
! END LOOP;
  
  
 
--- 1923,1929 
  <>
  WHILE expression LOOP
  statements
! END LOOP 
<>;
  
  
 
***
*** 2000,2006 
  <>
  FOR record_or_row IN 
query LOOP
  statements
! END LOOP;
  
   The record or row variable is successively assigned each row
   resulting from the query (which must be a
--- 2000,2006 
  <>
  FOR record_or_row IN 
query LOOP
  statements
! END LOOP 
<>;
  
   The record or row variable is successively assigned each row
   resulting from the query (which must be a
***
*** 2039,2045 
  <>
  FOR record_or_row IN EXECUTE 
text_expression LOOP 
  statements
! END LOOP;
  
   This is like the previous form, except that the source
   SELECT statement is specified as a string
--- 2039,2045 
  <>
  FOR record_or_row IN EXECUTE 
text_expression LOOP 
  statements
! END LOOP 
<>;
  
   This is like the previous form, except that the source
   SELECT statement is specified as a string
diff -c -r --new-file pgsql/src/pl/plpgsql/src/gram.y 
pgsql.01/src/pl/plpgsql/src/gram.y
*** pgsql/src/pl/plpgsql/src/gram.y 2005-06-24 13:11:25.0 +0200
--- pgsql.01/src/pl/plpgsql/src/gram.y  2005-06-25 15:21:22.0 +0200
***
*** 56,61 
--- 56,62 

   PLpgSQL_datum *initial_datum);
  staticvoid check_sql_expr(const char *stmt);
  staticvoid plpgsql_sql_error_callback(void *arg);
+ static void   check_labels(char *lbl, char *elbl, int lno);
  
  %}
  
***
*** 81,86 
--- 82,93 
int  n_initvars;
int  *initvarnos;
}   declhdr;
+   struct 
+   {
+   char *label;
+   int lineno;
+   List *list;
+   }   loop_body;
List*list;
PLpgSQL_type*dtype;
PLpgSQL_datum   *scalar;/* a VAR, 
RECFIELD, or TRIGARG */
***
*** 122,129 
  %typeopt_lblname opt_label
  %typeopt_exitlabel
  %typeexecsql_start
  
! %type   proc_sect proc_stmts stmt_else loop_body
  %type   proc_stmt pl_block
  %type   stmt_assign stmt_if stmt_loop stmt_while stmt_exit
  %type   stmt_return stmt_return_next stmt_raise stmt_execsql
--- 129,138 
  %typeopt_lblname opt_label
  %typeopt_exitlabel
  %typeexecsql_start
+ %typeopt_lbltext opt_endlabel
  
! %type   proc_sect proc_stmts stmt_else
! %type  loop_body
  %type   proc_stmt pl_block
  %type   stmt_assign stmt_if stmt_loop stmt_while stmt_exit
  %type   stmt_return stmt_return_next stmt_raise stmt_execsql
***
*** 248,257 
| ';'
;
  
! pl_block  : decl_sect K_BEGIN lno proc_sect exception_sect K_END
{
PLpgSQL_stmt_block *new;
  
new = 
palloc0(sizeof(PLpgSQL_stmt_block));
  
new->cmd_type   = 
PLPGSQL_STMT_BLOCK;
--- 257,268 
| ';'
;
  
! pl_block  : decl_sect K_BEGIN lno proc_sect exception_sect K_END 
opt_endlabel
{
PLpgSQL_stmt_block *new;
  
+   check_labels($1.label, $7, $3);
+   
 

Re: [HACKERS] pl/pgsql: END verbosity

[Peter Eisentraut]

Am Mittwoch, 22. Juni 2005 04:17 schrieb Neil Conway:
> In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
> is used to terminate IF blocks. This is needlessly verbose:

It is required by the SQL standard.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] pl/pgsql: END verbosity

[Neil Conway]

Jan Wieck wrote:

But what if they decide to allow

LOOP
-- ...
IF condition THEN
EXIT;
END LOOP;

at some point? There you'd get ambiguity.


ISTM this would be ambiguous in any case:

IF condition1 THEN
foo;
IF condition2 THEN
bar;
END IF;

-Neil

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] pl/pgsql: END verbosity

[Robert Treat]

On Wednesday 22 June 2005 11:41, Neil Conway wrote:
> Andrew Dunstan wrote:
> > But this doesn't make it easier to use - users don't just include those
> > who write it. The antecedent language of these, Ada, from which this
> > syntax comes, was explicitly designed to be reader-friendly as opposed to
> > writer-friendly, and this is a part of that.
>
> IMHO it is just needless verbiage that makes programs both harder to
> read *and* harder to write, albeit marginally so. I think there is a
> reason why Ada-style block terminators are in the minority among
> block-structured languages :)
>
> But obviously this is a matter of taste -- does anyone else like or
> dislike the current syntax?
>

-1 on the proposal to me... ambiguous END statements just looks like trouble 
to me.  I'd actually rather see you implement label...END LOOP label if you 
felt like you had to change *something*.

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] pl/pgsql: END verbosity

[Jan Wieck]

On 6/22/2005 1:29 AM, Neil Conway wrote:


Tom Lane wrote:

The long-term point in my mind is that removing syntactical
redundancy always reduces the ability to detect errors or report
errors acccurately


Lexical scoping is unambiguous in a language like PL/PgSQL. Since it is 
simple to determine whether a given END matches an IF, LOOP, or BEGIN, I 
don't see how it would reduce our "ability to detect errors or report 
errors accurately".



Consider for example the possibility that Oracle's next release adds
some new frammish that can't be duplicated because we chose not to
distinguish various forms of "END xxx" ...


As lexical scoping is still unambiguous, we could actually add a K_LOOP 
/ K_IF token to the input stream, if that would make you happier :) (Of 
course I'm not suggesting this -- the point is that as far as the parser 
is concerned, we should have precisely the same information for 
disambiguating the input as we used to have.)


BTW, I notice that Oracle actually allows:

<>
LOOP
 -- ...
END LOOP label;


But what if they decide to allow

LOOP
-- ...
IF condition THEN
EXIT;
END LOOP;

at some point? There you'd get ambiguity.


Jan




whereas we don't allow the optional label following END LOOP. Which goes 
to my general point: this frammish has existed in PL/SQL for a while, 
but it's not as if people are clamoring for us to implement it. I would 
wager that most people care about having *equivalent* features to 
PL/SQL, not exactly identical syntax. For example, the lack of 
autonomous transactions is something people have asked for in the past, 
because it *does* make porting PL/SQL applications more difficult. I 
can't see anyone losing any sleep because we are slightly more relaxed 
about the input we accept.


-Neil

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org



--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] pl/pgsql: END verbosity

[Merlin Moncure]

> > Neil Conway said:
> > > In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END
IF"
> > > is used to terminate IF blocks. This is needlessly verbose: we
could
> > > simply accept "END" in both cases without syntactic ambiguity. I'd
> like
> > >  to make this change, so that END can be used to terminate any
kind of
> > > block. There's no need to remove support for the present syntax,
of
> > > course, so there's no backward compatibility concern. Oracle's
PL/SQL
> > > does require "END IF" and "END LOOP", but folks interested in
maximum
> > > compatibility can always use those forms if they like.
> > >
> 
> Hello,
> 
> I prefer actual syntax too, Neil. The reason isn't compatibility with
> Oracle, but better readibility - it's mean more work with finishing
code
> but less with debugging

COBOL, which is a kissing-cousin of pl/sql, allows this.  You can have a
line terminator (a period) or a specialized block terminator.  Based on
my experience here I would suggest not allowing a choice.  It's a famous
source of bugs.

Merlin

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] pl/pgsql: END verbosity

[Pavel Stehule]

On Tue, 21 Jun 2005, Andrew Dunstan wrote:

> Neil Conway said:
> > In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
> > is used to terminate IF blocks. This is needlessly verbose: we could
> > simply accept "END" in both cases without syntactic ambiguity. I'd like
> >  to make this change, so that END can be used to terminate any kind of
> > block. There's no need to remove support for the present syntax, of
> > course, so there's no backward compatibility concern. Oracle's PL/SQL
> > does require "END IF" and "END LOOP", but folks interested in maximum
> > compatibility can always use those forms if they like.
> >

Hello,

I prefer actual syntax too, Neil. The reason isn't compatibility with 
Oracle, but better readibility - it's mean more work with finishing code 
but less with debugging

Regards
Pavel


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] pl/pgsql: END verbosity

[Alvaro Herrera]

On Wed, Jun 22, 2005 at 09:23:17AM -0700, Steve Atkins wrote:
> On Thu, Jun 23, 2005 at 01:41:49AM +1000, Neil Conway wrote:
> > Andrew Dunstan wrote:
> > >But this doesn't make it easier to use - users don't just include those who
> > >write it. The antecedent language of these, Ada, from which this syntax
> > >comes, was explicitly designed to be reader-friendly as opposed to
> > >writer-friendly, and this is a part of that.
> > 
> > IMHO it is just needless verbiage that makes programs both harder to 
> > read *and* harder to write, albeit marginally so. I think there is a 
> > reason why Ada-style block terminators are in the minority among 
> > block-structured languages :)
> > 
> > But obviously this is a matter of taste -- does anyone else like or 
> > dislike the current syntax?
> 
> "Like" is a bit strong. But it does make functions written in it easier
> to read. And given that the primary debugging methodolofy for pl/pgsql
> is "Look at it hard and see what might be incorrect" I can't see that
> as a bad thing.

Yeah, while we don't have good debugging support in pl/pgsql we
shouldn't be making it harder to read.  (FWIW, yes, I think it's useful
for those keywords to be required when you have to look at homongous
functions.)

-- 
Alvaro Herrera ()
"No renuncies a nada. No te aferres a nada."

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] pl/pgsql: END verbosity

[Steve Atkins]

On Thu, Jun 23, 2005 at 01:41:49AM +1000, Neil Conway wrote:
> Andrew Dunstan wrote:
> >But this doesn't make it easier to use - users don't just include those who
> >write it. The antecedent language of these, Ada, from which this syntax
> >comes, was explicitly designed to be reader-friendly as opposed to
> >writer-friendly, and this is a part of that.
> 
> IMHO it is just needless verbiage that makes programs both harder to 
> read *and* harder to write, albeit marginally so. I think there is a 
> reason why Ada-style block terminators are in the minority among 
> block-structured languages :)
> 
> But obviously this is a matter of taste -- does anyone else like or 
> dislike the current syntax?

"Like" is a bit strong. But it does make functions written in it easier
to read. And given that the primary debugging methodolofy for pl/pgsql
is "Look at it hard and see what might be incorrect" I can't see that
as a bad thing.

I'd trade a whole lot of "harder to write" for even some "likely to
work".

Cheers,
  Steve

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] pl/pgsql: END verbosity

[Neil Conway]

Andrew Dunstan wrote:

But this doesn't make it easier to use - users don't just include those who
write it. The antecedent language of these, Ada, from which this syntax
comes, was explicitly designed to be reader-friendly as opposed to
writer-friendly, and this is a part of that.


IMHO it is just needless verbiage that makes programs both harder to 
read *and* harder to write, albeit marginally so. I think there is a 
reason why Ada-style block terminators are in the minority among 
block-structured languages :)


But obviously this is a matter of taste -- does anyone else like or 
dislike the current syntax?


-Neil

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] pl/pgsql: END verbosity

[Andrew Dunstan]

Neil Conway said:
> Andrew Dunstan wrote:
>> I'm unkeen. I see no technical advantage - it's just a matter of
>> taste.
>
> There is no "technical advantage" to case insensitive keywords, or
> dollar quoting, or a variety of other programming language features
> that  don't change functionality but exist to make using the
> programming  language easier.
>


But this doesn't make it easier to use - users don't just include those who
write it. The antecedent language of these, Ada, from which this syntax
comes, was explicitly designed to be reader-friendly as opposed to
writer-friendly, and this is a part of that. I can tell you from experience
of programming Ada a long time ago that I have been profoundly grateful that
this was required in the language when disentangling a badly written 1000+
line long multibranch IF statement. And I still find myself having to hunt
for what sort of block a } is closing in C, and I still find it annoying.

>> We advertise that plpgsql is similar to plsql - we should not do
>> anything to make that less so IMNSHO.
>
> Do you *really* mean that? This principle would mean we should reject
> patches like the CONTINUE statement patch I just applied, for example,
> as PL/SQL has no such construct.
>

Well, perhaps I should have qualified that a bit - we shouldn't do it
gratuitously.

Getting the effect of CONTINUE for nested loops can be sufficiently hard
that it is arguable that implementing it is not just syntactic sugar. I seem
to recall muttering about how implementing GOTO wasn't worth the trouble.

>
>> Terseness is not always good, redundancy is not always bad.
>
> Granted -- but why is redundancy a good thing here?
>

see above

cheers

andrew




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] pl/pgsql: END verbosity

[Neil Conway]

Tom Lane wrote:

The long-term point in my mind is that removing syntactical
redundancy always reduces the ability to detect errors or report
errors acccurately


Lexical scoping is unambiguous in a language like PL/PgSQL. Since it is 
simple to determine whether a given END matches an IF, LOOP, or BEGIN, I 
don't see how it would reduce our "ability to detect errors or report 
errors accurately".



Consider for example the possibility that Oracle's next release adds
some new frammish that can't be duplicated because we chose not to
distinguish various forms of "END xxx" ...


As lexical scoping is still unambiguous, we could actually add a K_LOOP 
/ K_IF token to the input stream, if that would make you happier :) (Of 
course I'm not suggesting this -- the point is that as far as the parser 
is concerned, we should have precisely the same information for 
disambiguating the input as we used to have.)


BTW, I notice that Oracle actually allows:

<>
LOOP
-- ...
END LOOP label;

whereas we don't allow the optional label following END LOOP. Which goes 
to my general point: this frammish has existed in PL/SQL for a while, 
but it's not as if people are clamoring for us to implement it. I would 
wager that most people care about having *equivalent* features to 
PL/SQL, not exactly identical syntax. For example, the lack of 
autonomous transactions is something people have asked for in the past, 
because it *does* make porting PL/SQL applications more difficult. I 
can't see anyone losing any sleep because we are slightly more relaxed 
about the input we accept.


-Neil

---(end of broadcast)---
TIP 6: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] pl/pgsql: END verbosity

[Neil Conway]

Andrew Dunstan wrote:

I'm unkeen. I see no technical advantage - it's just a matter of taste.


There is no "technical advantage" to case insensitive keywords, or 
dollar quoting, or a variety of other programming language features that 
don't change functionality but exist to make using the programming 
language easier.



We advertise that plpgsql is similar to plsql - we should not do
anything to make that less so IMNSHO.


Do you *really* mean that? This principle would mean we should reject 
patches like the CONTINUE statement patch I just applied, for example, 
as PL/SQL has no such construct.


In any case, I think you are overestimating the value of strict PL/SQL 
compatibility. IMHO, PL/PgSQL should be a useful procedural programming 
language first, and a reimplementation of PL/SQL second. We should 
provide an equivalent feature (not necessarily with the same syntax) for 
all of PL/SQL's useful features, but I don't see the value in copying 
Oracle when PL/SQL's implementation of a feature is ugly, broken, or 
inconsistent with the rest of Postgres. It's not as if complete 
source-level compatibility with PL/SQL has been a goal for PL/PgSQL 
anyway (and besides, there are other people, like EnterpriseDB, who can 
provide that for those who need it).



Terseness is not always good, redundancy is not always bad.


Granted -- but why is redundancy a good thing here?

-Neil

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] pl/pgsql: END verbosity

[Tom Lane]

"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Neil Conway said:
>> Any objections?

> I'm unkeen. I see no technical advantage - it's just a matter of taste. We
> advertise that plpgsql is similar to plsql - we should not do anything to
> make that less so IMNSHO. Terseness is not always good, redundancy is not
> always bad.

That was my reaction too, though I'm too tired at this hour to phrase it
so well ;-).  The long-term point in my mind is that removing
syntactical redundancy always reduces the ability to detect errors or
report errors acccurately; and it may limit our freedom to introduce
new features later.  Consider for example the possibility that Oracle's
next release adds some new frammish that can't be duplicated because we
chose not to distinguish various forms of "END xxx" ...

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] pl/pgsql: END verbosity

[Andrew Dunstan]

Neil Conway said:
> In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
> is used to terminate IF blocks. This is needlessly verbose: we could
> simply accept "END" in both cases without syntactic ambiguity. I'd like
>  to make this change, so that END can be used to terminate any kind of
> block. There's no need to remove support for the present syntax, of
> course, so there's no backward compatibility concern. Oracle's PL/SQL
> does require "END IF" and "END LOOP", but folks interested in maximum
> compatibility can always use those forms if they like.
>
> Any objections?
>

I'm unkeen. I see no technical advantage - it's just a matter of taste. We
advertise that plpgsql is similar to plsql - we should not do anything to
make that less so IMNSHO. Terseness is not always good, redundancy is not
always bad.

cheers

andrew



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] pl/pgsql: END verbosity

[Josh Berkus]

Neil,

> In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
> is used to terminate IF blocks. This is needlessly verbose: we could
> simply accept "END" in both cases without syntactic ambiguity. I'd like
> to make this change, so that END can be used to terminate any kind of
> block. There's no need to remove support for the present syntax, of
> course, so there's no backward compatibility concern. Oracle's PL/SQL
> does require "END IF" and "END LOOP", but folks interested in maximum
> compatibility can always use those forms if they like.

No problem from me.   Since the parser checks for block closure for all 
block types, I can't see how this would be a problem.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[HACKERS] pl/pgsql: END verbosity

[Neil Conway]

In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF" 
is used to terminate IF blocks. This is needlessly verbose: we could 
simply accept "END" in both cases without syntactic ambiguity. I'd like 
to make this change, so that END can be used to terminate any kind of 
block. There's no need to remove support for the present syntax, of 
course, so there's no backward compatibility concern. Oracle's PL/SQL 
does require "END IF" and "END LOOP", but folks interested in maximum 
compatibility can always use those forms if they like.


Any objections?

-Neil

---(end of broadcast)---
TIP 6: Have you searched our list archives?

  http://archives.postgresql.org