Parser bug results in ambiguous errors/behaviour - Mailing list pgsql-hackers

From Gavin Sherry
Subject Parser bug results in ambiguous errors/behaviour
Date
Msg-id Pine.LNX.4.58.0509221647150.25615@linuxworld.com.au
Whole thread Raw
Responses Re: Parser bug results in ambiguous errors/behaviour
List 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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Minimally avoiding Transaction Wraparound in VLDBs
Next
From: Michael Glaesemann
Date:
Subject: Re: Minimally avoiding Transaction Wraparound in VLDBs