pl/pgsql: END verbosity

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

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

"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

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

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

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

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

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

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

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

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

Hi All,

Sorry if this isn¹t the right forum for this question... But, I noticed
that Alvaro wrote

³... we don't have good debugging support in pl/pgsql ...²

I got to thinking it¹d be kewl if PgAdmin3 supported an interactive debugger
for pl/pgsql. If anyone¹s interested in expertly tackling such a community
project, with some financial sponsorship from EDB, please contact me
privately.

--Denis Lussier
Founder & Chief Dweeb
EnterpriseDB

Denis Lussier <denisl@enterprisedb.com> writes:

I got to thinking it'd be kewl if PgAdmin3 supported an interactive debugger
for pl/pgsql.

That's been kicked around before, although I don't think anyone wants to
tie it to pgAdmin specifically. Check the archives...

regards, tom lane

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:

<<label>>
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. #
#================================================== JanWieck@Yahoo.com #

Tom Lane wrote:

Denis Lussier <denisl@enterprisedb.com> writes:

I got to thinking it'd be kewl if PgAdmin3 supported an interactive debugger
for pl/pgsql.

That's been kicked around before, although I don't think anyone wants to
tie it to pgAdmin specifically. Check the archives...

I didn't find anything relevant after a quick search, but if memory
serves, one of the objections to PgAdmin was that it was windows only.
This of course is no longer true as of PgAdmin III 1.0. It now support
Win32, Linux and FreeBSD. So perhaps that objection is no longer valid.

On Thu, Jun 23, 2005 at 01:40:18PM -0400, Matthew T. O'Connor wrote:

Tom Lane wrote:

Denis Lussier <denisl@enterprisedb.com> writes:

I got to thinking it'd be kewl if PgAdmin3 supported an interactive
debugger for pl/pgsql.

That's been kicked around before, although I don't think anyone wants to
tie it to pgAdmin specifically. Check the archives...

I didn't find anything relevant after a quick search, but if memory
serves, one of the objections to PgAdmin was that it was windows only.
This of course is no longer true as of PgAdmin III 1.0. It now support
Win32, Linux and FreeBSD. So perhaps that objection is no longer valid.

I think the point is that we will have to make some modifications to
PL/pgSQL, so why not make sure we write something that any tool can use?
Say, a well-defined BE/FE protocol extension.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)

Alvaro,

I agree, a protocol seems to generally be the best option.

-Jonah

Alvaro Herrera wrote:

Denis, all,

I got to thinking it¹d be kewl if PgAdmin3 supported an interactive
debugger for pl/pgsql.  If anyone¹s interested in expertly tackling such a
community project, with some financial sponsorship from EDB, please contact
me privately.

Just FYI, EMS Hitech has a windows-only PL/pgSQL debugger. So it's apparently
possible even with the current tech.

Overally, though, we'd want to support something command-line like the Perl
debug shell. Then any tool could use it.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Thursday 23 June 2005 14:21, Josh Berkus wrote:

Denis, all,

I got to thinking it¹d be kewl if PgAdmin3 supported an interactive
debugger for pl/pgsql.  If anyone¹s interested in expertly tackling such
a community project, with some financial sponsorship from EDB, please
contact me privately.

Just FYI, EMS Hitech has a windows-only PL/pgSQL debugger. So it's
apparently possible even with the current tech.

IIRC thier debugger is little more than BEGIN; SELECT foo(); ROLLBACK; which
isn't great as far as debuggers go.

Overally, though, we'd want to support something command-line like the Perl
debug shell. Then any tool could use it.

Uh... a lot of tools have issues executing stuff from the command line... what
we need is something sql driven, or at least that opeates at that level,
inside the db.

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