Re: record identical operator

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: record identical operator
Date: 2013-09-16 22:52:19
Message-ID: 20130916225219.GD27150@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
> > I can understand claiming that the risk is acceptable but arguing
> > it's not there seems extremly strange to me.
>
> It's not a risk.  It's why the operator exists. 

Pft. It's fine if the materialized view code uses it. I don't see the
danger there.
It's about users discovering it. If they notice it, they will use it
because "its a crapload faster" than normal row comparisons. And deals
with NULLs in a "simpler" way.

> Perhaps the name
> of the operator (===) or the fact that I've been using the
> shorthand description of "identical" instead of writing out "record
> image equals" in these emails has confused you.

If you really think that "confusing you" is the correct description for
concerns about users not understanding limitations (which you didn't
seem to know about), go ahead. Way to go to solicit feedback.

> I can stop using
> the shorter description and have absolutely no attachment to the
> operator name, if that helps.

You're unfortunately going to need operators if you want mergejoins to
work, right? If not I'd have said name it matview_needs_update() or
something like that... But yes, === certainly seems like a bad idea.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2013-09-16 22:57:03 Re: [PATCH] Revive line type
Previous Message Kevin Grittner 2013-09-16 22:26:08 Re: record identical operator