Thread

1. bug in 7.0

   Don Baccus <dhogaza@pacifier.com> — 2000-02-28T15:16:01Z

   This is probably related to Lockhart's changes to allow
   not null/not deferrable to work (foreign key stuff).  I'm
   sympathetic, I looked at gram.y for awhile myself trying to
   figure a way out of the problem and didn't find a good
   solution.
   
   Anyway:
   
   donb=# create table bar(i integer unique not null);
   ERROR:  parser: parse error at or near "not"
   donb=# create table bar(i integer not null unique);
   ERROR:  parser: parse error at or near "unique"
   donb=# create table bar(i integer unique);
   NOTICE:  CREATE TABLE/UNIQUE will create implicit index 'bar_i_key' for
   table 'bar'
   CREATE
   donb=# 
   
   
   Ouch.   Fails on "primary key not null", etc too (though the
   not null is redundant in this case).
   
   The data model I'm porting from Oracle fails several hundred
   times now because of this little problem...I guess my last
   snapshot was just before Thomas' committed those changes,
   otherwise I would've caught them before beta.
   
   
   
   - Don Baccus, Portland OR <dhogaza@pacifier.com>
     Nature photos, on-line guides, Pacific Northwest
     Rare Bird Alert Service and other goodies at
     http://donb.photo.net.
   
   

2. Re: [HACKERS] bug in 7.0

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-28T16:11:36Z

   Don Baccus <dhogaza@pacifier.com> writes:
   > This is probably related to Lockhart's changes to allow
   > not null/not deferrable to work (foreign key stuff).
   
   Yeah, we need a better answer for NOT DEFERRABLE.  Thomas just did a
   quick & dirty kluge to allow testing of foreign keys, but as you see
   it's broken a number of other things...
   
   I still like the idea of turning NOT NULL into a single token before
   it gets to the grammar, but Thomas was dissatisfied with that plan.
   
   			regards, tom lane
   
   

3. NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Jan Wieck <wieck@debis.com> — 2000-02-28T22:18:34Z

   Tom Lane wrote:
   
   > Don Baccus <dhogaza@pacifier.com> writes:
   > > This is probably related to Lockhart's changes to allow
   > > not null/not deferrable to work (foreign key stuff).
   >
   > Yeah, we need a better answer for NOT DEFERRABLE.  Thomas just did a
   > quick & dirty kluge to allow testing of foreign keys, but as you see
   > it's broken a number of other things...
   >
   > I still like the idea of turning NOT NULL into a single token before
   > it gets to the grammar, but Thomas was dissatisfied with that plan.
   
       I  would  be able to undo Thomas' changes to the parser (plus
       your fix for SEQUENCE) and put our idea  of  token  lookahead
       into instead. The changes are locally to gram.y, and anything
       works as expected.
   
       It's a kludge too, mucking around with a
   
           #define yylex() pg_yylex()
   
       at the  beginning,  then  later  #undef'ining  it  again  and
       creating  a  function pg_yylex() that calls the real yylex().
       Since we insist on bison and ship a gram.c  for  the  others,
       There can't be any portability problems.
   
       I'd  like  to  discuss  this  with Thomas on the phone before
       committing, but IIRC he's off right now. So  what  do  others
       think?
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #========================================= wieck@debis.com (Jan Wieck) #
   
   
   
   

4. Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Don Baccus <dhogaza@pacifier.com> — 2000-02-28T22:37:02Z

   At 11:18 PM 2/28/00 +0100, Jan Wieck wrote:
   
   >    I  would  be able to undo Thomas' changes to the parser (plus
   >    your fix for SEQUENCE) and put our idea  of  token  lookahead
   >    into instead. The changes are locally to gram.y, and anything
   >    works as expected.
   
   Look-ahead's a bit cleaner in principle than doing it in the lexer,
   IMO.  Still, it shouldn't be necessary.
   
   I was going to take a look at the relevant part of gram.y starting
   in about an hour, over coffee, to see if anything leaps out at me.
   
   Also, I think Thomas ought to have a chance to chime in and he's
   apparently back in touch with the world, because he's been e-mailing
   today.
   
   
   
   - Don Baccus, Portland OR <dhogaza@pacifier.com>
     Nature photos, on-line guides, Pacific Northwest
     Rare Bird Alert Service and other goodies at
     http://donb.photo.net.
   
   

5. Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-28T23:25:10Z

   wieck@debis.com (Jan Wieck) writes:
   >     I  would  be able to undo Thomas' changes to the parser (plus
   >     your fix for SEQUENCE) and put our idea  of  token  lookahead
   >     into instead. The changes are locally to gram.y, and anything
   >     works as expected.
   
   >     It's a kludge too, mucking around with a
   
   >         #define yylex() pg_yylex()
   
   >     at the  beginning,  then  later  #undef'ining  it  again  and
   >     creating  a  function pg_yylex() that calls the real yylex().
   >     Since we insist on bison and ship a gram.c  for  the  others,
   >     There can't be any portability problems.
   
   Um.  We do *not* insist on bison, and at least one platform that
   I work with would like to keep the option.  Please hold off on this.
   
   The other alternative that was discussed was to put the onus on
   analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
   and the other subclauses of foreign key clauses be independent
   clauses from the grammar's point of view; that is,
   
   	FOREIGN KEY blah blah NOT DEFERRABLE INITIALLY IMMEDIATE
   
   would be parsed as three separate constraint clauses producing three
   separate nodes in the column's constraint list.  Then analyze.c would
   make a pre-pass over the list to mark the FOREIGN KEY clause with the
   right values and remove the extraneous clauses.  (And to complain if
   any of them are not in the right place, of course.)
   
   This should get rid of the shift-reduce conflict, because there's
   no longer any need to consider shifting in the context of
   
   	FOREIGN KEY blah blah . NOT
   
   As far as the grammar is concerned, it can always reduce the FOREIGN
   KEY clause at this point; the NOT will introduce a separate clause in
   any case, so it doesn't matter whether NULL or DEFERRABLE follows it.
   
   This would be a little bit more work, but it would introduce no
   portability risk at all, and in theory it would let us produce better
   error messages than the generic "parse error near" message, for at least
   some kinds of mistakes.
   
   I don't recall whether Thomas liked that idea either ;-), but I'm coming
   around to the opinion that it's the best solution.
   
   			regards, tom lane
   
   

6. Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Jan Wieck <wieck@debis.com> — 2000-02-29T00:28:11Z

   Tom Lane wrote:
   
   > wieck@debis.com (Jan Wieck) writes:
   >
   > >     It's a kludge too, mucking around with a
   >
   > >         #define yylex() pg_yylex()
   >
   > >     at the  beginning,  then  later  #undef'ining  it  again  and
   >
   > Um.  We do *not* insist on bison, and at least one platform that
   > I work with would like to keep the option.  Please hold off on this.
   
       Oh - O.K. - wrong assumption. Interesting if such a construct
       works with other yacc implementations anyway.
   
   > The other alternative that was discussed was to put the onus on
   > analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
   > and the other subclauses of foreign key clauses be independent
   > clauses from the grammar's point of view; that is,
   > [...]
   
       Yepp, that was the third possible solution we  talked  about.
       No doubt that it is the best one, and something we both wanna
       see at the end. Only that I fear we cannot build it  in  time
       for  7.0  schedule.  Thus I assume we have to live 'now' with
       either Thomas' kludge (as you called it),  restricting  order
       of constraint clauses and introducing unpleasant "Why doesn't
       my query ..." questions, or my crude hack.  From  the  latter
       one,  I  expect  far less rumour because that's restricted to
       ppl NOT using bison BUT touching gram.y.
   
       At least this one will give us the option to delay the  final
       solution  until  7.1  or  until  we  shuffle  up  the  entire
       parser->rewriter->planner/optimizer->executor path. And  that
       without crippling the syntax from the users PoV.
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #========================================= wieck@debis.com (Jan Wieck) #
   
   
   
   

7. Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Don Baccus <dhogaza@pacifier.com> — 2000-02-29T00:31:41Z

   At 06:25 PM 2/28/00 -0500, Tom Lane wrote:
   
   >The other alternative that was discussed was to put the onus on
   >analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
   >and the other subclauses of foreign key clauses be independent
   >clauses from the grammar's point of view;
   
   Which, of course, they are in the SQL92 grammar...
   
   > that is,
   >
   >	FOREIGN KEY blah blah NOT DEFERRABLE INITIALLY IMMEDIATE
   >
   >would be parsed as three separate constraint clauses producing three
   >separate nodes in the column's constraint list.  Then analyze.c would
   >make a pre-pass over the list to mark the FOREIGN KEY clause with the
   >right values and remove the extraneous clauses.  (And to complain if
   >any of them are not in the right place, of course.)
   
   I just got back from my little coffee break spent reading the relevant bit
   of gram.y, and after looking at the gyrations Thomas went through in his
   patch I'm even more convinced that doing it "right" is not only right,
   but in the long run simpler.
   
   I think gram.y can be patched up to fix some of the more obvious 
   missing cases but it will make it even messier than it is now.  And
   it's already extremely messy.
   
   Again, I'm sympathetic to Thomas because I tried to find a quick and
   dirty work-around to Jan's original shift-reduce conflict several
   weeks ago, without success.  Thomas' change isn't quick and dirty,
   but rather complicated and messy and incomplete, but short of doing
   it "right" (i.e. as Tom explains above) there's no other way I can
   see.
   
   Other than stepping outside the parser, so to speak, to do token
   lookahead or to do a lexer kludge.  But these kludges only fix
   Jan's original problem - and Jan's original grammar isn't SQL92
   compliant...
   
   >I don't recall whether Thomas liked that idea either ;-), but I'm coming
   >around to the opinion that it's the best solution.
   
   Well, the current effort tries to avoid the general case by listing
   a bunch of possible combinations, which really doesn't feel right.
   
   
   
   - Don Baccus, Portland OR <dhogaza@pacifier.com>
     Nature photos, on-line guides, Pacific Northwest
     Rare Bird Alert Service and other goodies at
     http://donb.photo.net.
   
   

8. Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-29T00:45:02Z

   wieck@debis.com (Jan Wieck) writes:
   > Tom Lane wrote:
   >> The other alternative that was discussed was to put the onus on
   >> analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
   >> and the other subclauses of foreign key clauses be independent
   >> clauses from the grammar's point of view; that is,
   
   >     Yepp, that was the third possible solution we  talked  about.
   >     No doubt that it is the best one, and something we both wanna
   >     see at the end. Only that I fear we cannot build it  in  time
   >     for  7.0  schedule.
   
   Why not?  It's not *that* much work --- looked like maybe an
   evening's project to me.  If no one else wants to do it, I will.
   
   			regards, tom lane
   
   

9. Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

   Jan Wieck <wieck@debis.com> — 2000-02-29T00:55:09Z

   Tom Lane wrote:
   > wieck@debis.com (Jan Wieck) writes:
   > > Tom Lane wrote:
   > >> The other alternative that was discussed was to put the onus on
   > >> analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
   > >> and the other subclauses of foreign key clauses be independent
   > >> clauses from the grammar's point of view; that is,
   >
   > >     Yepp, that was the third possible solution we  talked  about.
   > >     No doubt that it is the best one, and something we both wanna
   > >     see at the end. Only that I fear we cannot build it  in  time
   > >     for  7.0  schedule.
   >
   > Why not?  It's not *that* much work --- looked like maybe an
   > evening's project to me.  If no one else wants to do it, I will.
   
       Your turn.
   
       Thomas  made  his,  IMHO already complained because crippling
       the user interface in a not stdconforming way.  My one  is  a
       bad hack and therefore deprecated by definition.
   
       Let's  look at all three possible implementations for 7.0 and
       judge after.
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #========================================= wieck@debis.com (Jan Wieck) #
   
   
   
   

10. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-02-29T05:54:56Z

    >     Thomas  made  his,  IMHO already complained because crippling
    >     the user interface in a not stdconforming way.  My one  is  a
    >     bad hack and therefore deprecated by definition.
    
    I did not claim to have the final form; I ran out of time before
    heading out on vacation. istm that solving the general case by
    unrolling clauses should not be exhaustively difficult. I will
    continue to pursue this as time permits.
    
    >     Let's  look at all three possible implementations for 7.0 and
    >     judge after.
    
    Sounds good.
    
                         - Thomas
    
    -- 
    Thomas Lockhart				lockhart@alumni.caltech.edu
    South Pasadena, California
    
    

11. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Don Baccus <dhogaza@pacifier.com> — 2000-02-29T14:30:59Z

    At 05:54 AM 2/29/00 +0000, Thomas Lockhart wrote:
    
    >I did not claim to have the final form; I ran out of time before
    >heading out on vacation.
    
    In retrospect, it shouldn't've gone into the beta at that point,
    then.  Crippling "unique not null" isn't merely an inconvenience.
    Dropping a bomb like this into beta the night before release
    and leaving town for nine days perhaps wasn't the best thing to
    do.   Perhaps we should avoid doing things like this in the future.
    
    Because of this, the web toolkit I'm porting is going out with
    6.5 only, rather than 6.5 or 7.0 beta with 7.0 beta recommended.
    It's a pity, bugs and some of our hacks around missing features 
    in 6.5 make portions of the toolkit differ in their output than
    the Oracle version.  This hurts the credibility of the port,
    to some degree, and simply adds ammunition to those who argue
    that trying to do this kind of project on top of Postgres is
    foolishness incarnate.
    
    It's REALLY a pity because the Feb 18th snapshot I took and
    tested, like earlier ones, was really solid.  The toolkit was
    looking great with the snapshot.
    
    >istm that solving the general case by
    >unrolling clauses should not be exhaustively difficult.
    
    I actually did the unrolling of the worst cases last night, took
    me about an hour with "Star Trek Voyager" on in the background
    as a distraction from how ugly this hack is.  Because, with all
    due respect, Thomas, it is an exceedingly ugly hack.  And you
    can't unroll enough to capture the grammar anyway, it's like
    trying to enumerate all possible expressions in the grammar
    rather than parse the general form.
    
    I ran into another problem, though, and presumed it was because
    of my hacking.  So I decided to roll back gram.y to the Feb
    18 snapshot, did a clean/make of the parser, rebuilt and reinstalled,
    and the thing still segtrapped on me.  
    
    I don't have time to dig deeper at the moment.  I'll look later
    tonight.  It would take me about 15 minutes to recreate my
    additional unrolling clauses, as well, but I'm hoping Tom was
    serious about taking the time to do it right as unrolling is
    NOT a solution.
    
    What's wrong with actually accepting the SQL92 grammar, anyway?
    
    > I will
    >continue to pursue this as time permits.
    
    "as time permits"?  This implies we live with an unusable beta
    in the interim?
    
    
    
    - Don Baccus, Portland OR <dhogaza@pacifier.com>
      Nature photos, on-line guides, Pacific Northwest
      Rare Bird Alert Service and other goodies at
      http://donb.photo.net.
    
    

12. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-02-29T16:37:08Z

    On Tue, 29 Feb 2000, Don Baccus wrote:
    
    > Because of this, the web toolkit I'm porting is going out with
    > 6.5 only, rather than 6.5 or 7.0 beta with 7.0 beta recommended.
    > It's a pity, bugs and some of our hacks around missing features 
    > in 6.5 make portions of the toolkit differ in their output than
    > the Oracle version.  This hurts the credibility of the port,
    > to some degree, and simply adds ammunition to those who argue
    > that trying to do this kind of project on top of Postgres is
    > foolishness incarnate.
    
    It's BETA. You're not supposed to use it in production work. Beta is a
    feature freeze, then we try to sort out the bugs.
    
    As far as I'm concerned it would hurt credibility of the port much more to
    "recommend" a beta version of a database server as its backend. If you
    need 7.0 for your port then you should have waited a month. While I agree
    that the parser "fixes" were less than ideal, we're not primarily
    developing PostgreSQL to work with your toolkit.
    
    > I actually did the unrolling of the worst cases last night, took
    > me about an hour with "Star Trek Voyager" on in the background
    > as a distraction from how ugly this hack is.  Because, with all
    > due respect, Thomas, it is an exceedingly ugly hack.  And you
    > can't unroll enough to capture the grammar anyway, it's like
    > trying to enumerate all possible expressions in the grammar
    > rather than parse the general form.
    
    The difference is that the expression space is infinite, whereas unrolling
    all column constraints should be on the order of a dozen or two. Better
    ideas are welcome of course.
    
    
    -- 
    Peter Eisentraut                  Sernanders väg 10:115
    peter_e@gmx.net                   75262 Uppsala
    http://yi.org/peter-e/            Sweden
    
    
    

13. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-02-29T16:39:52Z

    > >I did not claim to have the final form; I ran out of time before
    > >heading out on vacation.
    > In retrospect, it shouldn't've gone into the beta at that point,
    > then.  Crippling "unique not null" isn't merely an inconvenience.
    > Dropping a bomb like this into beta the night before release
    > and leaving town for nine days perhaps wasn't the best thing to
    > do.   Perhaps we should avoid doing things like this in the future.
    
    Lighten up Don! I put this in so Jan et al can get cracking on the
    referential integrity stuff in the column specification, and imho the
    feature and space of possible solutions is isolated and finite. Not a
    big risk for the first part of beta.
    
    <snip>
    > What's wrong with actually accepting the SQL92 grammar, anyway?
    
    ?? That is what we are trying to do.
    
    I'm not sure what your point is about "having to ship 6.5 instead of
    7.0" for your porting project. If you aren't willing to cope with
    small changes/features/breakage in a beta cycle you should stay away
    from betas.
    
    There is *no* reason you should think that the restriction on syntax
    in this area is a permanent feature or something that will persist
    through beta. If you are on such a tight schedule that you can't cope
    with a 2 week slip in a feature, or a 2 week breakage from your PoV,
    then beta isn't for you!!
    
    otoh, if you are planning on shipping after the 7.0 release, then
    there isn't a problem. And if you need a system which has *exactly*
    the behaviors of a couple of weeks ago, then use a snapshot from a
    couple of weeks ago. I'll prep and send you one if you would like.
    
    Regards.
    
                        - Thomas
    
    -- 
    Thomas Lockhart				lockhart@alumni.caltech.edu
    South Pasadena, California
    
    

14. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Don Baccus <dhogaza@pacifier.com> — 2000-02-29T17:33:33Z

    At 04:39 PM 2/29/00 +0000, Thomas Lockhart wrote:
    >> >I did not claim to have the final form; I ran out of time before
    >> >heading out on vacation.
    >> In retrospect, it shouldn't've gone into the beta at that point,
    >> then.  Crippling "unique not null" isn't merely an inconvenience.
    >> Dropping a bomb like this into beta the night before release
    >> and leaving town for nine days perhaps wasn't the best thing to
    >> do.   Perhaps we should avoid doing things like this in the future.
    >
    >Lighten up Don! I put this in so Jan et al can get cracking on the
    >referential integrity stuff in the column specification, and imho the
    >feature and space of possible solutions is isolated and finite. Not a
    >big risk for the first part of beta.
    
    No, I won't lighten up.  I said "in retrospect", and I used those
    words intentionally to suggest that IN THE FUTURE we might take
    more care.  What's the harm in learning from experience?
    
    An alternative might be to remove the following sentence from the
    release notes:
    
    "Don't be concerned this is a dot-zero release. PostgreSQL does its
    best to put out only solid releases, and this one is no exception."
    
    ><snip>
    >> What's wrong with actually accepting the SQL92 grammar, anyway?
    >
    >?? That is what we are trying to do.
    
    Your unrolling technique doesn't and can't accept the SQL92 grammar.
    That should be obvious.  You don't seriously intend to enumerate
    all possible combinations of constraints and constraint attributes,
    do you?  It's the wrong way to go about it.
    
    >I'm not sure what your point is about "having to ship 6.5 instead of
    >7.0" for your porting project. If you aren't willing to cope with
    >small changes/features/breakage in a beta cycle you should stay away
    >from betas.
    
    This is NOT a small change/breakage.  I'm astonished that that the
    removal of "unique not null" and "not null unique" would be considered
    "small".   Of course, other perfectly legal and previously accepted
    constraints are rejected, too.
    
    >There is *no* reason you should think that the restriction on syntax
    >in this area is a permanent feature or something that will persist
    >through beta. If you are on such a tight schedule that you can't cope
    >with a 2 week slip in a feature, or a 2 week breakage from your PoV,
    >then beta isn't for you!!
    
    In MHO delaying beta would've been better if a better solution couldn't
    be lashed in, because this is a serious breakage. 
    
    Or, make more modest claims about the stability of betas.  If release
    notes and publicity made it clear that PG betas aren't expected to be
    production, or near-production, quality then people like me wouldn't
    hold this expectation.
    
    >otoh, if you are planning on shipping after the 7.0 release, then
    >there isn't a problem. And if you need a system which has *exactly*
    >the behaviors of a couple of weeks ago, then use a snapshot from a
    >couple of weeks ago. I'll prep and send you one if you would like.
    
    I've got my own from three days before beta, thank you.
    
    
    
    - Don Baccus, Portland OR <dhogaza@pacifier.com>
      Nature photos, on-line guides, Pacific Northwest
      Rare Bird Alert Service and other goodies at
      http://donb.photo.net.
    
    

15. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Don Baccus <dhogaza@pacifier.com> — 2000-02-29T17:51:09Z

    At 05:37 PM 2/29/00 +0100, Peter Eisentraut wrote:
    >On Tue, 29 Feb 2000, Don Baccus wrote:
    >
    >> Because of this, the web toolkit I'm porting is going out with
    >> 6.5 only, rather than 6.5 or 7.0 beta with 7.0 beta recommended.
    >> It's a pity, bugs and some of our hacks around missing features 
    >> in 6.5 make portions of the toolkit differ in their output than
    >> the Oracle version.  This hurts the credibility of the port,
    >> to some degree, and simply adds ammunition to those who argue
    >> that trying to do this kind of project on top of Postgres is
    >> foolishness incarnate.
    >
    >It's BETA. You're not supposed to use it in production work. Beta is a
    >feature freeze, then we try to sort out the bugs.
    
    So is our web toolkit release.  So is the AOLserver Version 3 that
    we're using.  We're putting out a beta suite, so to speak.  I didn't
    make that clear.  Obviously we're not going to put out a production
    version with all-beta componets.
    
    "Don't be concerned this is a dot-zero release. PostgreSQL does its 
    best to put out only solid releases, and this one is no exception."
    
    I'm now concerned.  I wasn't Feb 18th.
    
    Mind you, I made my recommendation that we use 7.0 beta after having
    used it in my porting work for about a month, without problems.  Just
    as I've been using AOLserver version 3, also without problem.
    
    So it's not like I blindly made a decision out of ignorance, I worked
    with the upcoming beta in order to make an intellegent decision.  As
    of Feb 18th, the upcoming beta worked much better with our stuff
    than 6.5, and that's the truth.
    
    >As far as I'm concerned it would hurt credibility of the port much more to
    >"recommend" a beta version of a database server as its backend.
    
    Again, I didn't make it clear that our port is also a beta, and that
    we're only encouraging that people experiment with it, not put up
    production web sites, for the next couple of months at least.  Sorry
    for that confusion.
    
    In that context, I feel comfortable with using tested components even
    if they're beta.
    
    Postgres benefits from that aggressiveness as the beta will get some
    serious testing in this environment.  AOLserver V3 beta won't benefit
    to the same degree because it's so (ahem) solid that it's being used
    on production web sites using the Oracle version of this toolkit.
    
    ...
    
    >we're not primarily
    >developing PostgreSQL to work with your toolkit.
    
    I've never suggested that.  Jose Soares (sp?) found the same bug
    almost simultaneously.  We're talking vanilla SQL92.  I can use my
    Feb 18th snapshot, and will if this doesn't get fixed quickly.  My
    concern's a lot more general.
    
    I'm not being small-minded or selfish.
    
    >> I actually did the unrolling of the worst cases last night, took
    >> me about an hour with "Star Trek Voyager" on in the background
    >> as a distraction from how ugly this hack is.  Because, with all
    >> due respect, Thomas, it is an exceedingly ugly hack.  And you
    >> can't unroll enough to capture the grammar anyway, it's like
    >> trying to enumerate all possible expressions in the grammar
    >> rather than parse the general form.
    >
    >The difference is that the expression space is infinite, whereas unrolling
    >all column constraints should be on the order of a dozen or two.
    
    Actually, the column constraint stuff is infinite, too - in the given
    SQL92 grammar.  Restrictions that exist are due to semantics.  The
    traditional means of dealing with this - pardon me for being a professional
    compiler writer, I was born this way and can't help myself - is to
    implement semantic restrictions via semantic analysis, not syntactic
    kludges.
    
    It sounds like Tom intends to take a whack at this approach.  I'd
    offer, but my time's tight at the moment.
    
    
    
    
    - Don Baccus, Portland OR <dhogaza@pacifier.com>
      Nature photos, on-line guides, Pacific Northwest
      Rare Bird Alert Service and other goodies at
      http://donb.photo.net.
    
    

16. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-29T18:14:34Z

    Don Baccus <dhogaza@pacifier.com> writes:
    > An alternative might be to remove the following sentence from the
    > release notes:
    > "Don't be concerned this is a dot-zero release. PostgreSQL does its
    > best to put out only solid releases, and this one is no exception."
    
    Uh, Don, that's wording that we expect will apply to the 7.0 *release*.
    We did not claim that the beta version has no known bugs.
    
    > [ much ranting snipped ]
    
    Thomas made an engineering judgment that supporting beta-testing of all
    the new foreign key features was more important than having a first beta
    release with no regression in the parser.  You can argue that he made
    the wrong choice (I'm not sure if he did or not), but I don't think
    jumping on him like this is appropriate.
    
    			regards, tom lane
    
    

17. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Marc G. Fournier <scrappy@hub.org> — 2000-02-29T18:34:07Z

    Don, I'm tired of listening to you constantly berating ppl who are doing
    *alot* of work to get PostgreSQL to a release state ... we are currently
    in a *BETA* period, which means that we are trying *fix bugs* ... some of
    those fixes will let other bugs creep in, and it is expected by those
    playing with *non release level* software ...
    
    IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
    that you need *release level* software ...
    
    I've warned once before, as has Bruce ... this is the last one.  If you
    can't report bugs without being antagonistic about it, I will have to ask
    you to leave -hackers and wait for the release to happen ... 
    
    As all our others once said: "if you can't say something nice, don't say
    anything at all" ... and, quite frankly, silence from your end of the
    world until the release is made would be appreciated by all ...
    
    If, when we release, you are *still* having problems,please feel free to
    let us know in a *NON* antagonistic way ...
    
    On Tue, 29 Feb 2000, Don Baccus wrote:
    
    > At 04:39 PM 2/29/00 +0000, Thomas Lockhart wrote:
    > >> >I did not claim to have the final form; I ran out of time before
    > >> >heading out on vacation.
    > >> In retrospect, it shouldn't've gone into the beta at that point,
    > >> then.  Crippling "unique not null" isn't merely an inconvenience.
    > >> Dropping a bomb like this into beta the night before release
    > >> and leaving town for nine days perhaps wasn't the best thing to
    > >> do.   Perhaps we should avoid doing things like this in the future.
    > >
    > >Lighten up Don! I put this in so Jan et al can get cracking on the
    > >referential integrity stuff in the column specification, and imho the
    > >feature and space of possible solutions is isolated and finite. Not a
    > >big risk for the first part of beta.
    > 
    > No, I won't lighten up.  I said "in retrospect", and I used those
    > words intentionally to suggest that IN THE FUTURE we might take
    > more care.  What's the harm in learning from experience?
    > 
    > An alternative might be to remove the following sentence from the
    > release notes:
    > 
    > "Don't be concerned this is a dot-zero release. PostgreSQL does its
    > best to put out only solid releases, and this one is no exception."
    > 
    > ><snip>
    > >> What's wrong with actually accepting the SQL92 grammar, anyway?
    > >
    > >?? That is what we are trying to do.
    > 
    > Your unrolling technique doesn't and can't accept the SQL92 grammar.
    > That should be obvious.  You don't seriously intend to enumerate
    > all possible combinations of constraints and constraint attributes,
    > do you?  It's the wrong way to go about it.
    > 
    > >I'm not sure what your point is about "having to ship 6.5 instead of
    > >7.0" for your porting project. If you aren't willing to cope with
    > >small changes/features/breakage in a beta cycle you should stay away
    > >from betas.
    > 
    > This is NOT a small change/breakage.  I'm astonished that that the
    > removal of "unique not null" and "not null unique" would be considered
    > "small".   Of course, other perfectly legal and previously accepted
    > constraints are rejected, too.
    > 
    > >There is *no* reason you should think that the restriction on syntax
    > >in this area is a permanent feature or something that will persist
    > >through beta. If you are on such a tight schedule that you can't cope
    > >with a 2 week slip in a feature, or a 2 week breakage from your PoV,
    > >then beta isn't for you!!
    > 
    > In MHO delaying beta would've been better if a better solution couldn't
    > be lashed in, because this is a serious breakage. 
    > 
    > Or, make more modest claims about the stability of betas.  If release
    > notes and publicity made it clear that PG betas aren't expected to be
    > production, or near-production, quality then people like me wouldn't
    > hold this expectation.
    > 
    > >otoh, if you are planning on shipping after the 7.0 release, then
    > >there isn't a problem. And if you need a system which has *exactly*
    > >the behaviors of a couple of weeks ago, then use a snapshot from a
    > >couple of weeks ago. I'll prep and send you one if you would like.
    > 
    > I've got my own from three days before beta, thank you.
    > 
    > 
    > 
    > - Don Baccus, Portland OR <dhogaza@pacifier.com>
    >   Nature photos, on-line guides, Pacific Northwest
    >   Rare Bird Alert Service and other goodies at
    >   http://donb.photo.net.
    > 
    > ************
    > 
    
    Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
    Systems Administrator @ hub.org 
    primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
    
    
    

18. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Don Baccus <dhogaza@pacifier.com> — 2000-02-29T18:51:06Z

    At 01:14 PM 2/29/00 -0500, Tom Lane wrote:
    >Don Baccus <dhogaza@pacifier.com> writes:
    >> An alternative might be to remove the following sentence from the
    >> release notes:
    >> "Don't be concerned this is a dot-zero release. PostgreSQL does its
    >> best to put out only solid releases, and this one is no exception."
    >
    >Uh, Don, that's wording that we expect will apply to the 7.0 *release*.
    >We did not claim that the beta version has no known bugs.
    
    Hmmm...OK, I can see this.  It's not clear, though, because you get
    there from the main web page which is discussing the beta.  
    
    >
    >> [ much ranting snipped ]
    >
    >Thomas made an engineering judgment that supporting beta-testing of all
    >the new foreign key features was more important than having a first beta
    >release with no regression in the parser.  You can argue that he made
    >the wrong choice (I'm not sure if he did or not), but I don't think
    >jumping on him like this is appropriate.
    
    I said "in retrospect" and "in the future" ... I'm merely suggesting
    that perhaps in the future we might be more conservative.  
    
    
    
    
    
    - Don Baccus, Portland OR <dhogaza@pacifier.com>
      Nature photos, on-line guides, Pacific Northwest
      Rare Bird Alert Service and other goodies at
      http://donb.photo.net.
    
    

19. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Don Baccus <dhogaza@pacifier.com> — 2000-02-29T19:06:22Z

    At 02:34 PM 2/29/00 -0400, The Hermit Hacker wrote:
    
    >IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
    >that you need *release level* software ...
    
    No problem, I'll unsubscribe.
    
    >If, when we release, you are *still* having problems,please feel free to
    >let us know in a *NON* antagonistic way ...
    
    Save bug reports until release?  OK, if that's what you want.
    
    
    
    
    - Don Baccus, Portland OR <dhogaza@pacifier.com>
      Nature photos, on-line guides, Pacific Northwest
      Rare Bird Alert Service and other goodies at
      http://donb.photo.net.
    
    

20. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Vince Vielhaber <vev@michvhf.com> — 2000-02-29T19:18:41Z

    On 29-Feb-00 Don Baccus wrote:
    > At 01:14 PM 2/29/00 -0500, Tom Lane wrote:
    >>Don Baccus <dhogaza@pacifier.com> writes:
    >>> An alternative might be to remove the following sentence from the
    >>> release notes:
    >>> "Don't be concerned this is a dot-zero release. PostgreSQL does its
    >>> best to put out only solid releases, and this one is no exception."
    >>
    >>Uh, Don, that's wording that we expect will apply to the 7.0 *release*.
    >>We did not claim that the beta version has no known bugs.
    > 
    > Hmmm...OK, I can see this.  It's not clear, though, because you get
    > there from the main web page which is discussing the beta.  
    
    With the key word here being "beta".   
    
    Vince.
    -- 
    ==========================================================================
    Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
       128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
            Online Campground Directory    http://www.camping-usa.com
           Online Giftshop Superstore    http://www.cloudninegifts.com
    ==========================================================================
    
    
    
    

21. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Marc G. Fournier <scrappy@hub.org> — 2000-02-29T20:05:23Z

    On Tue, 29 Feb 2000, Don Baccus wrote:
    
    > At 02:34 PM 2/29/00 -0400, The Hermit Hacker wrote:
    > 
    > >IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
    > >that you need *release level* software ...
    > 
    > No problem, I'll unsubscribe.
    > 
    > >If, when we release, you are *still* having problems,please feel free to
    > >let us know in a *NON* antagonistic way ...
    > 
    > Save bug reports until release?  OK, if that's what you want.
    
    No, bug reports are most welcome, antagonistic comments aren't ... big
    difference ...
    
    
    
    

22. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Jan Wieck <wieck@debis.com> — 2000-02-29T23:52:58Z

    > At 02:34 PM 2/29/00 -0400, The Hermit Hacker wrote:
    >
    > >IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
    > >that you need *release level* software ...
    >
    > No problem, I'll unsubscribe.
    
        NO!
    
        Your  input  and  code-contribution to the FK project was far
        too important. In  fact,  without  you  FK  would  have  been
        implemented  fundamentally  wrong.  So  I  would  miss you on
        -hackers.
    
    > >If, when we release, you are *still* having problems,please feel free to
    > >let us know in a *NON* antagonistic way ...
    >
    > Save bug reports until release?  OK, if that's what you want.
    
        It's not wat I want at least.
    
        Back to the roots. Thomas, from my personal PoV, is a  little
        too much after "do it in the grammar if possible at all". But
        he's the core member to take care about  compliance  and  the
        like.   Hackers  (like me) tend to let go with something that
        works, but it's him to assure the parsers  future  is  great,
        wide  open.  Finally  it's  the mixture in the core team that
        makes Postgres successful, so I'm happy with Thomas having  a
        sharp eye on it.
    
        In the actual case, we need to see what can be done until 7.0
        release.  If we cannot produce a clean  solution  during  the
        next  weeks,  I'm  sure that "backward compatibility" has the
        higher weight than avoiding my crude  hack  into  the  parser
        (it'll stay for one release only anyway).
    
        What  I  suggest  is,  take  it  as  it  is. We use to have a
        friendly and nice ground noise in our mailing lists. So  this
        kind  of  discussion, tending to become flame wars, should be
        taken off list at least (IMHO avoided at all, but I'm  farest
        the last person to judge).
    
    
    Jan
    
    --
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #========================================= wieck@debis.com (Jan Wieck) #
    
    
    
    

23. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Hannu Krosing <hannu@tm.ee> — 2000-03-01T20:13:20Z

    Jan Wieck wrote:
    > 
    >     What  I  suggest  is,  take  it  as  it  is. We use to have a
    >     friendly and nice ground noise in our mailing lists. So  this
    >     kind  of  discussion, tending to become flame wars, should be
    >     taken off list at least (IMHO avoided at all, but I'm  farest
    >     the last person to judge).
    >
    
    Maybe we need psql-flamewars@postgresql.org where we could migrate 
    these threads ? or even psql-hackers-flamewars@postgresql.org ;)
    
    I just read on NYTimes direct that a consulting firm has started 
    educating businesmens wives to not slurp soup or misbehave in other 
    ways.
    
    We could possibly hire them to consult the hackers list too ;)
    
    I'm sure PostgreSQL Inc. would accept donations to that end ;-p
    
    ---------
    Hannu
    (answers to psql-flamewars@postgresql.org please)
    
    

24. Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

    Vince Vielhaber <vev@michvhf.com> — 2000-03-01T20:24:34Z

    On 01-Mar-00 Hannu Krosing wrote:
    > (answers to psql-flamewars@postgresql.org please)
    
    I wonder if we could get Marc to create psql-flamewars and just route it
    to /dev/null :)
    
    Vince.
    -- 
    ==========================================================================
    Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
       128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
            Online Campground Directory    http://www.camping-usa.com
           Online Giftshop Superstore    http://www.cloudninegifts.com
    ==========================================================================