On 2013-09-16 14:39:30 -0700, Kevin Grittner wrote:
> Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2013-09-16 16:58:21 -0400, Noah Misch wrote:
> >> memcmp() has served well for HOT and for _equalConst(); why
> >> would it suddenly fall short for MV maintenance?
> >
> > I don't have a problem using it internally, I have a problem
> > exposing the capability to sql.
>
> ... like we do in *pattern ops and the
That's still an absurd comparison. pattern ops have a defined behaviour,
even for multibyte characters. After all, you can simply have a UTF-8
database with C collation. Remember, in a C collation pattern ops can
use normal indexes.
The only thing that happens is that multibyte chars are sorted
differently. They aren't sorted basically randomly or anything.
> suppress_redundant_updates_trigger() function?
You get superflous trigger calls. So what. It's not usable for anything
but a trigger.
> I'm really having trouble understanding what problem you have with
> this. Can you describe a scenario where someone shoots themselves
> in the foot with it, because I'm not seeing any?
It certainly will be surprising to just about anyone that something like:
SELECT * FROM foo WHERE whatever_composite_or_row === '(...)';
may not return rows where there's no SQL level discernible difference
(even by looking at the text conversion) between
whatever_composite_or_row and '(...)' because e.g. of the aforementioned
array null bitmaps.
I can understand claiming that the risk is acceptable but arguing it's
not there seems extremly strange to me.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services