Thread: bug in 7.0
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 Serviceand other goodies at http://donb.photo.net.
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
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) #
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 Serviceand other goodies at http://donb.photo.net.
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
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 bothwanna see at the end. Only that I fear we cannot build it in time for 7.0 schedule. Thus I assume we have tolive 'now' with either Thomas' kludge (as you called it), restricting order of constraint clauses and introducingunpleasant "Why doesn't my query ..." questions, or my crude hack. From the latter one, I expect farless 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 usersPoV. 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) #
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
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 Serviceand other goodies at http://donb.photo.net.
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) #
> 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
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 Serviceand other goodies at http://donb.photo.net.
> >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
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
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
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
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
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
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/moor less at Pop4 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
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 ...
> 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 withsomething that works, but it's him to assure the parsers future is great, wide open. Finally it's the mixturein 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, butI'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) #
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)
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/moor less at Pop4 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================