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, compiled by GCC egcs-2.91.66
(1 row)

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

Mon, 08 Jan 2001 10:32:09 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
ALL, ANY bug?
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

Sun, 07 Jan 2001 22:06:26 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: ALL, ANY bug? 
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

Mon, 08 Jan 2001 16:04:03 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: ALL, ANY bug? 
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

Mon, 08 Jan 2001 03:26:47 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: ALL, ANY bug? 
> 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

Mon, 08 Jan 2001 18:12:56 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: ALL, ANY bug? 