Re: New pg_lsn type doesn't have hash/btree opclasses - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New pg_lsn type doesn't have hash/btree opclasses
Date
Msg-id 21585.1399761291@sss.pgh.pa.us
Whole thread Raw
In response to Re: New pg_lsn type doesn't have hash/btree opclasses  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-05-10 19:19:22 -0300, Fabr�zio de Royes Mello wrote:
>> Sorry but I don't understand why it's too late. The 9.4 branch not been
>> created yet.

> The problem is that once the beta is in progress (starting tomorrow),
> the projects tries to avoid changes which require a dump and restore (or
> pg_upgrade). Since the patch changes the catalog it'd require that.

Exactly.  If this isn't in before beta1, it's not going in, unless perhaps
we encounter some bug bad enough to force an initdb later in beta.
Which is certainly possible, and if it did happen there might be room
to reconsider.  But the same policy means there is zero margin for error
with a catalog-changing patch applied right before beta starts, which
is what we're debating here.

As a comparison point, in a nearby thread we're debating renaming
jsonb_hash_ops, which is a sufficiently mechanical change that I'd
not be too afraid to do it the day before beta.  But there are enough
ways to screw up a new operator class that I'm very afraid of putting
one in this weekend.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: New pg_lsn type doesn't have hash/btree opclasses
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: New pg_lsn type doesn't have hash/btree opclasses