plpgsql on 8.0b4 bug?
It seems that 8.0B4's plpgsql does not diagnose 'ELSIF' being
misspelled as 'ELSEIF' nearly as readily as did 7.4.x. 7.4 emits a
compile error at the right place, whereas 8.0b4 seems to treat
misspelled 'ELSEIF' blocks as unreachable code, making it quite hard to
diagnose what is actually amiss. If not plpgsql coding often, the
difference in spelling can be rather hard to see even when staring at
the docs.
Attached is a sample script used to massage data in a table from a bad
representation to a little better one (with misspellings in place).
Here's a minimal table definition to run it:
create table unit (
id int8 not null primary key,
pets boolean not null,
petscondition text
);
insert into unit values (1, true, 'Outside Only');
8.0B4 results:
[dynamic-94:~/cvs/social/misc-db-utils] jlrobins% psql < pets.sql
BEGIN
ALTER TABLE
CREATE FUNCTION
ERROR: No code determined for unit 1, t, "Outside Only"
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ROLLBACK
7.4.6 results:
xs2 /tmp> psql ssc_sav < pets.sql
BEGIN
ALTER TABLE
CREATE FUNCTION
ERROR: syntax error at or near "ELSEIF" at character 1
CONTEXT: PL/pgSQL function "fix_pets" line 16 at SQL statement
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
COMMIT
Many thanks in advance,
James
Attachments:
James Robinson <jlrobins@socialserve.com> writes:
7.4.6 results:
xs2 /tmp> psql ssc_sav < pets.sql
BEGIN
ALTER TABLE
CREATE FUNCTION
ERROR: syntax error at or near "ELSEIF" at character 1
CONTEXT: PL/pgSQL function "fix_pets" line 16 at SQL statement
Um ... I get the "no code determined" message in 7.4.6 too, and indeed
in every version of plpgsql (ok, I didn't try before 7.2). Given the
way plpgsql works, it'd be hard to make it do anything else. It thinks
that ELSEIF (or any other unrecognized keyword) is a SQL command keyword.
regards, tom lane
Hmm. Teach me to not send in the exact script / dataset that caused the
issue. Indeed, I must have (luckily) had a separate syntax error in the
version that caused the 7.4.6 parser to trip up on the ELSEIF line (it
did happen else I'd still be staring at the thing).
Humble apologies and thanks.
----
James Robinson
Socialserve.com
James Robinson <jlrobins@socialserve.com> writes:
Hmm. Teach me to not send in the exact script / dataset that caused the
issue. Indeed, I must have (luckily) had a separate syntax error in the
version that caused the 7.4.6 parser to trip up on the ELSEIF line (it
did happen else I'd still be staring at the thing).
It occurs to me that one simple thing we could do is make plpgsql accept
both ELSIF and ELSEIF as legal spellings of the keyword. This seems a
bit ugly but I can't think of any really good objections.
regards, tom lane
Between ugly #1 and ugly #2, I'd think that a wart teaching it that
'ELSEIF' is not a valid manner to start a statement (i.e. following a
semicolon) would be preferable. Allowing us hacks to write functions
containing both spellings makes the language look poor since it ought
to slap us into formal shape. This isn't [insert a lossy SQL
implementation or slop-inspiring scripting language here]. We're
typesafe and syntax checking!
On Nov 18, 2004, at 12:09 PM, Tom Lane wrote:
It occurs to me that one simple thing we could do is make plpgsql
accept
both ELSIF and ELSEIF as legal spellings of the keyword. This seems a
bit ugly but I can't think of any really good objections.
----
James Robinson
Socialserve.com