Teodor Sigaev <[EMAIL PROTECTED]> writes: > % echo 'SELECT count(*) FROM tst WHERE ROW(tst.*) IS NULL;' | psql wow > SET > count > ------- > 0 > (1 row)
Hm, it turns out that this works: select * from int8_tbl x where row(x.q1,x.q2) is null; but not this: select * from int8_tbl x where row(x.*) is null; EXPLAIN tells the tale: regression=# explain select * from int8_tbl x where row(x.q1,x.q2) is null; QUERY PLAN ----------------------------------------------------------- Seq Scan on int8_tbl x (cost=0.00..1.05 rows=1 width=16) Filter: ((q1 IS NULL) AND (q2 IS NULL)) (2 rows) regression=# explain select * from int8_tbl x where row(x.*) is null; QUERY PLAN ----------------------------------------------------------- Seq Scan on int8_tbl x (cost=0.00..1.05 rows=1 width=16) Filter: (x.* IS NULL) (2 rows) Apparently what's happening is that gram.y's makeRowNullTest() bursts the RowExpr apart into individual isnull tests. Now that RowExpr expansion can change the number of items in the row, it's clearly premature to do that processing in gram.y --- we should move it to parse analysis. Part of the issue is that ExecEvalNullTest simply tests for whether the presented Datum is null, which I think is impossible for a whole-row Var coming from a table (but it could happen for a row-returning function's result, for example). I think that according to the letter of the spec, an IS [NOT] NULL test should "drill down" into rowtype datums and check nullness of the individual row fields. Probably the same is true for array datums. Moving makeRowNullTest() doesn't seem like a big deal, but changing ExecEvalNullTest would take some added code. Do we want to tackle that during beta, or hold off till 8.3? An argument for doing it now is that we just added nulls-in-arrays in 8.2, and it'd be good if the semantics of that were right the first time rather than changing later. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend