Thread: Re: bit types
> Bruce, > > The bit-type that is in contrib is useless as it stands. Those are > only C-routines to implement the functionality, and there are none of > the SQL functions to actually make these usable. This really needs to be > integrated with postgres proper. I don't know how to go about this and > that is why I asked for help. I'm prepared to do whatever SQL function > definitions are needed, do the regression tests etc. Would it be better > to go back to the hackers mailing list to ask for help? Has this missed > 7.0 now? If so, we'd better remove the bit-type from contrib. 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 to keep it in contrib and add it as soon as 7.0 finalizes and we move to 7.1. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Mar 01, 2000 at 11:36:52AM -0500, Bruce Momjian wrote: > > Bruce, > > > > The bit-type that is in contrib is useless as it stands. Those are > > only C-routines to implement the functionality, and there are none of > > the SQL functions to actually make these usable. This really needs to be > > integrated with postgres proper. I don't know how to go about this and > > that is why I asked for help. I'm prepared to do whatever SQL function > > definitions are needed, do the regression tests etc. Would it be better > > to go back to the hackers mailing list to ask for help? Has this missed > > 7.0 now? If so, we'd better remove the bit-type from contrib. > > 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? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
"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
On Wed, Mar 01, 2000 at 01:46:00PM -0500, Tom Lane wrote: > "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. > Agreed. > 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. Right, that's the _other_ current thread. ;-) > > 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... That's how I understood it, as well. It's just that Bruce had (at one time) offered to do the intergration/development of this type, and one interpretation of what he posted was that he had the code, but hadn't integrated it, because of the "no initdb" rule. Since Bruce tends to be the man for submissions from non-core developers, I just wanted to make sure everyone was on the same page. On a completely unrelated note: Apparently, there was a "bug fix" to SQL92, published in 1996, that goes by the name: Technical Corrigendum 1:1996 to ISO/IEC 9075:1992 According to the www.iso.ch site in Switzerland, this thing is 80 pages long. Even given the usual front matter, indices, and appendices, there's got to be something in there that we need to know. Hmm, it's marked as free. Perhaps I'll see if I can order it somewhere. Anyone seen this? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
> > > The bit-type that is in contrib is useless as it stands. Those are > > > only C-routines to implement the functionality, and there are none of > > > the SQL functions to actually make these usable. This really needs to be > > > integrated with postgres proper. I don't know how to go about this and > > > that is why I asked for help. I'm prepared to do whatever SQL function > > > definitions are needed, do the regression tests etc. Would it be better > > > to go back to the hackers mailing list to ask for help? Has this missed > > > 7.0 now? If so, we'd better remove the bit-type from contrib. > > > > 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? No, we usually avoid initdb if at all possible during beta. A new data type is not enough reason for it. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Mar 01, 2000 at 01:11:32PM -0600, Ross J. Reedstrom wrote: > > On a completely unrelated note: Apparently, there was a "bug fix" to > SQL92, published in 1996, that goes by the name: > > Technical Corrigendum 1:1996 to ISO/IEC 9075:1992 > > According to the www.iso.ch site in Switzerland, this thing is 80 > pages long. Even given the usual front matter, indices, and appendices, > there's got to be something in there that we need to know. Hmm, it's > marked as free. Perhaps I'll see if I can order it somewhere. > > Anyone seen this? > Following up to myself: Turns out there was _another_ TC published in 1999: ISO/IEC 9075:1992/Cor 3:1999 (Don't ask _me_ where Cor 2 went ;-) This one's 112 pages. Hmm, time to call my local librarian and see how one gets a hold of ISO standards around here. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
> > 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... > > That's how I understood it, as well. It's just that Bruce had (at one > time) offered to do the intergration/development of this type, and one > interpretation of what he posted was that he had the code, but hadn't > integrated it, because of the "no initdb" rule. Since Bruce tends to be > the man for submissions from non-core developers, I just wanted to make > sure everyone was on the same page. No, I have not written the code. I have been pretty busy and did not go though my mailbox like I normally do before beta time. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > Bruce, > > > > The bit-type that is in contrib is useless as it stands. Those are > > only C-routines to implement the functionality, and there are none of > > the SQL functions to actually make these usable. This really needs to be > > integrated with postgres proper. I don't know how to go about this and > > that is why I asked for help. I'm prepared to do whatever SQL function > > definitions are needed, do the regression tests etc. Would it be better > > to go back to the hackers mailing list to ask for help? Has this missed > > 7.0 now? If so, we'd better remove the bit-type from contrib. > > 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 > to keep it in contrib and add it as soon as 7.0 finalizes and we move to > 7.1. Fine by me either way. My systems still run on a non-SQL compliant bit-type I did earlier. Whenever you get round to it, give me a shout and I'll do whatever I can to help. Cheers, Adriaan