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

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

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

"Andrew Dunstan" <andrew@dunslane.net> 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

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

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:

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

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

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 (<alvherre[a]surnet.cl>)
"No renuncies a nada. No te aferres a nada."

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