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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
