Row-wise Comparison

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Row-wise Comparison
Date: 2013-09-10 21:32:56
Message-ID: 1378848776.70700.YahooMailNeo@web162902.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Johnston 2013-09-10 21:36:37 Re: Question regarding Sync message and unnamed portal
Previous Message Marti Raudsepp 2013-09-10 20:56:09 Re: PostgreSQL 9.3 beta breaks some extensions "make install"