Re: New pg_lsn type doesn't have hash/btree opclasses

On Sat, May 10, 2014 at 9:51 AM, Fabrízio de Royes Mello
<fabriziomello@gmail.com> wrote:
>
> On Fri, May 9, 2014 at 9:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Fabrízio de Royes Mello <fabriziomello@gmail.com> writes:
>> > On Fri, May 9, 2014 at 8:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> I think it's really too late for this for 9.4.  At this point it's
>> >> less than 48 hours until beta1 wraps, and we do not have the bandwidth
>> >> to do anything but worry about stabilizing the features we've already
>> >> got.
>>
>> > But it's a very small change with many benefits, and Michael acted very
>> > proactive to make this happens.
>>
>> [ shrug... ]  "proactive" would have been doing this a month ago.
>> If we're going to ship a release, we have to stop taking new features
>> at some point, and we are really past that point for 9.4.
>>
>> And, to be blunt, this is not important enough to hold up the release
>> for, nor to take any stability risks for.  It should go into the next
>> commitfest cycle where it can get a non-rushed review.
>>
>
> I agree with you that is too late to add *new features*.
>
> But I agree with Andres when he said this is a regression introcuced in the
> pg_lsn patch.
>
> So we'll release a version that break a simple query like that:
>
> fabrizio=# SELECT DISTINCT (g.i||'/0')::pg_lsn f FROM generate_series(1,
> 100) g(i), generate_series(1, 5);
> ERROR:  could not identify an equality operator for type pg_lsn
> LINE 1: SELECT DISTINCT (g.i||'/0')::pg_lsn f FROM generate_series(1...
>                          ^

I agree that this is not new feature but just the fix of oversight of
the pg_lsn patch.
Without such opclass, we cannot execute even such simple query.

Regards,

--
Fujii Masao