Re: pg ANY/SOME ambiguity wrt sql standard?
От | Tom Lane |
---|---|
Тема | Re: pg ANY/SOME ambiguity wrt sql standard? |
Дата | |
Msg-id | 29221.1083163797@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg ANY/SOME ambiguity wrt sql standard? (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pg ANY/SOME ambiguity wrt sql standard?
|
Список | pgsql-hackers |
Fabien COELHO <coelho@cri.ensmp.fr> writes: > I'm looking into adding sql standard aggregates EVERY/ANY/SOME. > It seems to me that there is a syntax ambiguity with ANY and SOME: > CREATE TABLE bla(b BOOL); > SELECT TRUE = ANY(b) FROM bla; AFAICS this ambiguity is built into the SQL standard, and in fact it's possible to generate cases that are legally parseable either way: SELECT foo.x = ANY((SELECT bar.y FROM bar)) FROM foo; The parenthesized sub-select could be a plain <value expression>, in which case ANY must be an aggregate function call, or we could regard it as a <table subquery>, in which case we've got a <quantified comparison predicate>. These interpretations could both work, if the sub-select yields only one row, but they won't necessarily give the same answer. So I think that the SQL committee shot themselves in the foot when they decided it was a good idea to call the boolean-OR aggregate "ANY", and our addition of an array option isn't the fundamental problem. Anyone know if SQL2003 fixed this silliness? regards, tom lane
В списке pgsql-hackers по дате отправления: