Re: [HACKERS] Re: bit types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: bit types
Date: 2000-03-01 18:46:00
Message-ID: 6295.951936360@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Ross J. Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-03-01 19:06:47 Re: [HACKERS] having and union in v7beta
Previous Message Peter Eisentraut 2000-03-01 18:35:44 Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)