> 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, Pennsylvania 19026

Wed, 1 Mar 2000 11:36:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: bit types
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

Wed, 1 Mar 2000 11:24:54 -0600
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Re: [HACKERS] Re: bit types
"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

Wed, 01 Mar 2000 13:46:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: bit types 
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

Wed, 1 Mar 2000 13:11:32 -0600
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Re: [HACKERS] Re: bit types
> > >     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, Pennsylvania 19026

Wed, 1 Mar 2000 14:23:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re: bit types
> > 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, Pennsylvania 19026

Wed, 1 Mar 2000 14:28:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re: bit types
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


Wed, 1 Mar 2000 13:30:14 -0600
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
SQL92 standard corrections
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


Wed, 01 Mar 2000 22:23:27 +0200
Adriaan Joubert <a.joubert@albourne.com>
Re: bit types