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.

Mon, 28 Feb 2000 07:16:01 -0800
Don Baccus <dhogaza@pacifier.com>
bug in 7.0
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

Mon, 28 Feb 2000 11:11:36 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] bug in 7.0 
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) #



Mon, 28 Feb 2000 23:18:34 +0100 (CET)
wieck@debis.com (Jan Wieck)
NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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.

Mon, 28 Feb 2000 14:37:02 -0800
Don Baccus <dhogaza@pacifier.com>
Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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

Mon, 28 Feb 2000 18:25:10 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0) 
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) #



Tue, 29 Feb 2000 01:28:11 +0100 (CET)
wieck@debis.com (Jan Wieck)
Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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.

Mon, 28 Feb 2000 16:31:41 -0800
Don Baccus <dhogaza@pacifier.com>
Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0) 
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

Mon, 28 Feb 2000 19:45:02 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0) 
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) #



Tue, 29 Feb 2000 01:55:09 +0100 (CET)
wieck@debis.com (Jan Wieck)
Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
>     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

Tue, 29 Feb 2000 05:54:56 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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.

Tue, 29 Feb 2000 06:30:59 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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


Tue, 29 Feb 2000 17:37:08 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
> >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

Tue, 29 Feb 2000 16:39:52 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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.

Tue, 29 Feb 2000 09:33:33 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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.

Tue, 29 Feb 2000 09:51:09 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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

Tue, 29 Feb 2000 13:14:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0) 

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 


Tue, 29 Feb 2000 14:34:07 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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.

Tue, 29 Feb 2000 10:51:06 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0) 
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.

Tue, 29 Feb 2000 11:06:22 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

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
==========================================================================



Tue, 29 Feb 2000 14:18:41 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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 ...



Tue, 29 Feb 2000 16:05:23 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
> 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) #



Wed, 1 Mar 2000 00:52:58 +0100 (CET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
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)

Wed, 01 Mar 2000 22:13:20 +0200
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

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
==========================================================================



Wed, 01 Mar 2000 15:24:34 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)