Re: record identical operator

On Mon, Sep 23, 2013 at 2:46 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Anyway, that is exactly what Kevin is proposing to do here and, to be
> clear, he's NOT proposing to use the binary-identical semantics to
> identify the row to be updated. That will happen using the semantics
> of whatever index the user chooses to create on the PK column.
> Rather, he's only using the binary-identical to decide which rows are
> completely unchanged. I might be wrong here, but it seems to me that
> that renders most of your argument here moot. Under Kevin's proposal,
> changing a citext column that acts as a PK for the matview WON'T cause
> the row to be deleted and reinserted, but what it will do is say, oh,
> it's the same row (the values are equal) but the case is different
> (the rows are not binary-equal), let me go update the PK column with
> the new value. From where I stand, that seems like exactly the right
> behavior. What do you think should happen instead?

Ah, I'm wrong here. It is true that we use the unique index semantics
to compare the results of rerunning the query to what's in the view,
but it's not true (currently) that we ever do updates on the view as
opposed to delete-and-reinsert. Apparently that code got (mostly)
ripped out at some point, but I was confused by a comment that wasn't
fully updated to reflect the new reality.

Still, I believe that most of the points I'm making here remain valid,
because the key assumption you seem to be making is that Kevin is
proposing to use binary-identical semantics throughout, and that's not
true. Old rows and new candidate rows are matched up using the
user-specified opclass, but binary-identical. Binary-identical just
determines whether to replace the rows.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company