Обсуждение: 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