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, compiled by 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
Show quoted text
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