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
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 |