On 2013-09-16 14:39:30 -0700, Kevin Grittner wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
