Re: [HACKERS] Parser bug results in ambiguous errors/behaviour

2005-09-22 Thread Gavin Sherry
On Thu, 22 Sep 2005, Tom Lane wrote: > Gavin Sherry <[EMAIL PROTECTED]> writes: > > template1=# update foo set i=2,b='t' and t='bar' where i=1; > > UPDATE 1 > > This is perfectly legal SQL. If it doesn't do what you intended, > well, too bad. We're not going to "fix" it. Hmmm. Okay. It wasn't t

Re: [HACKERS] Parser bug results in ambiguous errors/behaviour

2005-09-22 Thread Tom Lane
Gavin Sherry <[EMAIL PROTECTED]> writes: > template1=# update foo set i=2,b='t' and t='bar' where i=1; > UPDATE 1 This is perfectly legal SQL. If it doesn't do what you intended, well, too bad. We're not going to "fix" it. regards, tom lane ---(e

Re: [HACKERS] Parser bug results in ambiguous errors/behaviour

2005-09-22 Thread Michael Paesold
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

[HACKERS] Parser bug results in ambiguous errors/behaviour

2005-09-22 Thread Gavin Sherry
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'