Mark Kirkwood-2 wrote
> Postgres supports many procedural languages (e.g plperl, plpython) and all
> these have different
> grammar rules from SQL - and from each other. We can't (and shouldn't)
> try altering them to be similar to SQL - it would defeat the purpose of
> providing a procedural environment where the given language works as
> advertised.
>
> So in the case of plpgsql - it needs to follow the Ada grammar,
> otherwise it would be useless.
I do not follow the "useless" conclusion - what, present day, does Ada got
to do with it? And the request is to alter only plpgsql, not "all the other
languages". To the casual end-user plpgsql is an internal language under
our full control and installed by default in all new releases. Is it really
unreasonable to expect us to design in some level of coordination between it
and SQL?
Cross-compatibility is a valid reason though I'm guessing with all the
inherent differences between our standard PL and other database's PLs that
making this change would not be a materially noticeable additional
incompatibility.
I'll even accept language consistency and "not worth the effort of
special-casing" but mostly because the error is immediate and obvious, and
the "solution" is simple and readily learned.
A side observation: why does "DECLARE" not require a block-end keyword but
instead "BEGIN" acts as effectively both start and end? BEGIN, IF, FOR,
etc... all come in pairs but DECLARE does not.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/why-semicolon-after-begin-is-not-allowed-in-postgresql-tp5779905p5780245.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
