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

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-05-10 19:19:22 -0300, Fabrzio 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