Обсуждение: ALL, ANY bug?

It seems ALL and ANY (SOME) have problems with the parser.

test=# select * from t1 where i <> all(0,1);
ERROR:  parser: parse error at or near "0"
test=# select * from t1 where i = any (0,1);
ERROR:  parser: parse error at or near "0"
test=# select version();                               version                                 
------------------------------------------------------------------------PostgreSQL 7.1beta2 on i686-pc-linux-gnu,
compiledby GCC egcs-2.91.66
 
(1 row)

Note that if (0,1) is a subselect, it works fine.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> It seems ALL and ANY (SOME) have problems with the parser.

I see no problem here.  Those are only defined for sub-selects.
SQL92 8.7 says:
        <quantified comparison predicate> ::=             <row value constructor> <comp op> <quantifier> <table
subquery>
        <quantifier> ::= <all> | <some>
        <all> ::= ALL
        <some> ::= SOME | ANY

and that is the only appearance of ANY in the grammar ...
        regards, tom lane

You are right. However, SQL92 spec allows:

select * from t1 where i <> all values(0,1);

which is not allowed in PostgreSQL...
--
Tatsuo Ishii

> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > It seems ALL and ANY (SOME) have problems with the parser.
> 
> I see no problem here.  Those are only defined for sub-selects.
> SQL92 8.7 says:
> 
>          <quantified comparison predicate> ::=
>               <row value constructor> <comp op> <quantifier> <table subquery>
> 
>          <quantifier> ::= <all> | <some>
> 
>          <all> ::= ALL
> 
>          <some> ::= SOME | ANY
> 
> and that is the only appearance of ANY in the grammar ...
> 
>             regards, tom lane

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> You are right. However, SQL92 spec allows:
> select * from t1 where i <> all values(0,1);

No, I still disagree.  The ANY/ALL constructs compare a single row on
the left side with all the rows produced by the query on the right.
"values(0,1)" is effectively the same as "SELECT 0,1", ie, it is a
query that happens to produce just one row.  The above is illegal in
SQL92 because the lefthand side is not a two-item row.

The semantics you seem to be looking for is "scalar IN/NOT IN list",
which we do have.  ANY/ALL is a different animal.

It's true that we don't accept values(...) as a subquery, but that's
only one aspect of this example.
        regards, tom lane

> No, I still disagree.  The ANY/ALL constructs compare a single row on
> the left side with all the rows produced by the query on the right.
> "values(0,1)" is effectively the same as "SELECT 0,1", ie, it is a
> query that happens to produce just one row.  The above is illegal in
> SQL92 because the lefthand side is not a two-item row.

Oh, I see your point. values(0,1) = SELECT 0,1", which is one row
constructor. Sorry for the confusion.
--
Tatsuo Ishii