This is almost but not quite entirely unlike the NULL row issues
Bruce has been raising lately. It is related to some
infrastructure work I've been doing to fix some edge conditions I
discovered (based on reviewing issues raised by Noah) with REFRESH
MATERIALIZED VIEW CONCURRENTLY and also with work to implement
incremental maintenance of materialized views. I intend to
implement an operator for "rowvar is identical to rowvar", along
with related operators to support merge joins based on this. It's
actually done and pretty well tested, but needs documentation
before I post the patch. I don't want to jump the gun on
discussing details of that patch here, but ran into a problem when
I went to write the docs, which is what I want *this* thread to be
about.
The docs in question are here, and actually discuss comparisons of
what the SQL spec calls "row value constructors" and what the docs
call row_constructors:
http://www.postgresql.org/docs/devel/static/functions-comparisons.html#ROW-WISE-COMPARISON
They don't begin to document things like this:
test=# select pg_typeof(row(1, null::text));
pg_typeof
-----------
record
(1 row)
test=# select row(1, null::text) = row(1, null::text);
?column?
----------
(1 row)
test=# select pg_typeof(row(1, null::text)::record);
pg_typeof
-----------
record
(1 row)
test=# select row(1, null::text) = row(1, null::text)::record;
?column?
----------
t
(1 row)
The operators and sequencing involving actual records seems to be
different from that for row value constructors, and it appears to
be for good reason -- so that indexing will work correctly.
My questions:
Did I miss somewhere that the docs do cover this?
If not, do we want to describe it? Why not?
If we don't want to document the above, would the same arguments
apply to the operators I'm adding? (i.e., Do we want to avoid docs
on these, possibly on the basis of them being an internal
implementation detail?)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
