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?  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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 по дате отправления:

Предыдущее
От: "Thomas Hallgren"
Дата:
Сообщение: Re: Advice regarding configuration parameters
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: PITR Phase 1 - Code Overview (1)