Parser bug results in ambiguous errors/behaviour

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Parser bug results in ambiguous errors/behaviour
Date: 2005-09-22 06:56:26
Message-ID: Pine.LNX.4.58.0509221647150.25615@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

A bug/short coming in the parser leads to some pretty ambiguous errors
and/or foot shooting. Consider the following:

template1=# create table foo(i int, b bool, t text);
CREATE TABLE
template1=# insert into foo values(1, 'f', 'foo');
INSERT 0 1
template1=# update foo set i=2,b='t' and t='bar' where i=1;
UPDATE 1

Now there's an error in the SQL: "b='t' AND t='bar'". We don't detect
this. Result:

template1=# select * from foo;
i | b | t
---+---+-----
2 | f | foo
(1 row)

It gets more interesting:

template1=# update foo set b='t', i=2 and t='bar' where i=1;
ERROR: argument of AND must be type boolean, not type integer

Now, obviously the SQL is invalid but I think we should detect it. This
happens in HEAD, 8.0 and 7.2 -- and I presume other releases.

Comments?

Thanks,

Gavin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2005-09-22 07:15:26 Re: Minimally avoiding Transaction Wraparound in VLDBs
Previous Message David Fetter 2005-09-22 06:55:41 Re: Minimally avoiding Transaction Wraparound in VLDBs