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(at)gmail(dot)com> wrote:
>
> On Fri, May 9, 2014 at 9:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
>> > On Fri, May 9, 2014 at 8:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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