Re: Parser bug results in ambiguous errors/behaviour
От | Michael Paesold |
---|---|
Тема | Re: Parser bug results in ambiguous errors/behaviour |
Дата | |
Msg-id | 00ff01c5bf5c$a61493b0$0f01a8c0@zaphod обсуждение исходный текст |
Ответ на | Parser bug results in ambiguous errors/behaviour (Gavin Sherry <swm@linuxworld.com.au>) |
Список | pgsql-hackers |
Gavin Sherry wrote: > 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 Read it as: update foo set=2, b=('t' and t='bar') where i=1; This works because: 't' can be translated to boolean true, t='bar' to boolean false, (true and false) becomes false, of course. > template1=# select * from foo; > i | b | t > ---+---+----- > 2 | f | foo > (1 row) Seems to be the correct result, at least if the syntax without parenthesis is allowed by the SQL spec. > 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 update foo set b='t', i=(2 and t='bar') where i=1; This is supposed to fail. There is no (at least implicit) cast from integer to boolean. So 2 cannot be converted to a boolean value and the boolean AND operator fails. It comes down to the question if the query is valid syntax in the first place. The answers PostgreSQL gives are correct nevertheless. Best Regards, Michael Paesold
В списке pgsql-hackers по дате отправления: