Re: record identical operator

Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-09-16 10:58:01 -0700, Kevin Grittner wrote:
>> Andres Freund <andres@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