Re: [HACKERS] Re: bit types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: bit types
Date
Msg-id 6295.951936360@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: bit types  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
Responses Re: [HACKERS] Re: bit types  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
List pgsql-hackers
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
>> I clearly dropped the ball on this one.  Don't think it can go into 7.0
>> because it would require catalog changes/initdb.  However, I would like

> Hmm, I thought the hard and fast rule was no initdb _after_ release. Surely
> this sort of thing is what beta (especially beta1) is for?

Actually, it's not the initdb that bothers me --- it's that we'd be
talking about dropping in code that is not only not tested, but not
even written yet.  It seems a tad late in the 7.0 cycle for that.

Specifically, what's in contrib is only the C functions to support a BIT
data type.  Not only do we not have the SQL function definitions, but we
don't have the datatype, nor do we have the parser support needed for
BIT and BIT VARYING (or have you forgotten that those require special
syntax for their length specifications?)  So this code is a long way
from being ready for prime time; it's only part of what's needed,
not all of it.

Possibly I misunderstand the rules we set for beta phase, but my
understanding was not so much "no initdbs" as "no new-feature
development".  This sure looks like it needs some more feature
development...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] having and union in v7beta