Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-09-16 10:58:01 -0700, Kevin Grittner wrote: >> Andres Freund <and...@2ndquadrant.com> wrote: >>> On 2013-09-16 10:46:53 -0700, Kevin Grittner wrote: >>>> I don't recall seeing anyone posting regarding the existing >>>> undocumented record comparison operators. Nor do I recall >>>> seeing anyone posting about the undocumented pattern >>>> comparison operators. >>> >>> I've used and have seen them being used in client code... >> >> Which, the record operators or the text pattern operators (which >> ignore collations and multi-byte character considerations and >> just use memcmp())? > > I was referring to the text pattern ops. But I've seen the record > ones as well.
>> Is the fact that you have seen them used in client code even >> though they are not documented an argument for or against adding >> documentation for them? > > Neither. It's an argument that providing operators with confusing > behaviours will not go unnoticed/unused. It is true that there are likely to be some who find the new operators useful and will read the code to determine how to use them, just as they apparently did for the undocumented operators which already exist. > I don't really think the record identical and pattern ops > situations are comparable. The latter has a well defined > behaviour (using the C locale basically) and is only useable for > types where it's well defined. But it is *not* restricted to text in the C locale. It uses memcmp() on text values even if they contain multi-byte characters and use collations which require different sequencing. > The proposed identical operator returns false for comparisons of > actually equal data, That is the point of it. It tells you whether the record images are byte-for-byte identical for all values within the record. In some cases a detected difference clearly causes a user-visible difference; in others it is merely a performance or storage-space difference. For example in your array example the array with the unnecessary bitmap attached to it takes an extra eight bytes on disk, for no apparent benefit. The point is that code which wants to know whether those are identical images can detect that they are not. This works by default for all types, without having to track down which types are capable of doing this for "equal" values or in which cases the differences are user-visible. > that's quite different imo. Sorting a string based on its byte image, with no regard to its collation or character boundaries, is what these text pattern operators do, and it is exactly what my patch does. My patch just provides such a test for all data types within a record by default, rather than requiring a new opfamily for every type. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
