There have been some people who have said they want a 6.6 release with
beta to start on February 1.  They are Tom Lane, Thomas Lockhart, and
myself.  Jan and Peter Eisentraut have said they will be ready on that
date.

Seems foreign key ability would be enough to justify a 6.6.

Comments?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 10 Dec 1999 00:44:55 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
6.6 release
Bruce Momjian wrote:

> There have been some people who have said they want a 6.6 release with
> beta to start on February 1.  They are Tom Lane, Thomas Lockhart, and
> myself.  Jan and Peter Eisentraut have said they will be ready on that
> date.
>
> Seems foreign key ability would be enough to justify a 6.6.
>
> Comments?

>From a user's perspective, that would be great. Our application is composed
of over 130 C++ class objects (its about 100K lines of C++) and the move to
6.5 meant:

1) A change throughout the code to lock tables appropriately to support the
refint.c code (which itself doesn't work for cascading updates) under MVCC

2) Keep using 6.4 which isn't all that hot for concurrent access, or

3) Wait for referential integrity...and pray the race condition isn't
triggered under 6.5 for tables being altered.

Due to the nature of our application, and the number of people actually
updating and deleting base tables whose keys would require a cascading
delete/update, we choose #3...... :-)

Mike Mascari



Fri, 10 Dec 1999 01:37:30 -0500
Mike Mascari <mascarm@mascari.com>
Re: [HACKERS] 6.6 release
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Seems foreign key ability would be enough to justify a 6.6.

Even without foreign keys, we have enough bugfixes in place to justify
a 6.6 release, I think.  If Jan can get some amount of foreign key
support working before Feb, that'd be a nice bonus --- but it's not
really necessary.

The way I see it, we should push what we have out the door, and then
settle in for a long slog on 7.0.  We need to do WAL, querytree
redesign, long tuples, function manager changeover, date/time type
unification, and probably a couple other things that I don't remember
at this time of night.  These are all appropriate for "7.0" because
they are big items and/or will involve some loss of backward
compatibility.  Before we start in on that stuff, it'd be good to
consolidate the gains we already have.  Almost every day I find myself
saying to someone "that's fixed in current sources".  7.0 is still
a long way away, so we ought to get the existing improvements out
to our users.

(In short, Bruce persuaded me: we ought to do a 6.6 cycle.)

			regards, tom lane

Fri, 10 Dec 1999 01:37:49 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.6 release 
On Fri, 10 Dec 1999, Bruce Momjian wrote:

> There have been some people who have said they want a 6.6 release with
> beta to start on February 1.  They are Tom Lane, Thomas Lockhart, and
> myself.  Jan and Peter Eisentraut have said they will be ready on that
> date.
> 
> Seems foreign key ability would be enough to justify a 6.6.
> 
> Comments?

So we'd be looking at Beta on Feb 1st, with a release around Apr 1st, and
beta for 7 being around June 1st, with 7 release for Sept 1st?

IMHO, 7 is waiting for Vadim/WAL...we're doing a 6.6 due to him being
indisposed until Mar/Apr, correct?

Just want to get this clarified, that's all :)

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 10 Dec 1999 02:55:18 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.6 release
On Fri, 10 Dec 1999, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems foreign key ability would be enough to justify a 6.6.
> 
> Even without foreign keys, we have enough bugfixes in place to justify
> a 6.6 release, I think.  If Jan can get some amount of foreign key
> support working before Feb, that'd be a nice bonus --- but it's not
> really necessary.
> 
> The way I see it, we should push what we have out the door, and then
> settle in for a long slog on 7.0.  We need to do WAL, querytree
> redesign, long tuples, function manager changeover, date/time type
> unification, and probably a couple other things that I don't remember
> at this time of night.  These are all appropriate for "7.0" because
> they are big items and/or will involve some loss of backward
> compatibility.  Before we start in on that stuff, it'd be good to
> consolidate the gains we already have.  Almost every day I find myself
> saying to someone "that's fixed in current sources".  7.0 is still
> a long way away, so we ought to get the existing improvements out
> to our users.

Wait, now I'm confused...so between 6.6 and 7, we're talking another year
anyway? *raised eyebrow*  Just curious about your 'long slog' above :)

Here's a question...should we beta on Feb 1st but make it 7.0?  If we are
going to be looking for a "long slog" for 7, why not "freeze" things on
Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...

Like, what point do we call things a major release?  In a sense, MVCC
probably should have been considered a large enough overhaul to warrant
7.0, no?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 10 Dec 1999 03:08:50 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.6 release 
The Hermit Hacker wrote:
> 
> Wait, now I'm confused...so between 6.6 and 7, we're talking another year
> anyway? *raised eyebrow*  Just curious about your 'long slog' above :)
> 
> Here's a question...should we beta on Feb 1st but make it 7.0?  If we are
> going to be looking for a "long slog" for 7, why not "freeze" things on
> Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> 
> Like, what point do we call things a major release?  In a sense, MVCC
> probably should have been considered a large enough overhaul to warrant
> 7.0, no?

So, may be call next after 6.6 release just 6.7 ? -:)
Does it so matter - v7, v8? I would be happy with 6.7 -:)

Vadim

Fri, 10 Dec 1999 15:04:46 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] 6.6 release
The Hermit Hacker <scrappy@hub.org> writes:
>> 7.0 is still a long way away, so we ought to get the existing
>> improvements out to our users.

> Wait, now I'm confused...so between 6.6 and 7, we're talking another year
> anyway? *raised eyebrow*  Just curious about your 'long slog' above :)

I hope not a year ... but I could easily believe we have three to six
months of development ahead, if 7.0 is to contain all the stuff I
mentioned.

> Here's a question...should we beta on Feb 1st but make it 7.0?  If we are
> going to be looking for a "long slog" for 7, why not "freeze" things on
> Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> Like, what point do we call things a major release?  In a sense, MVCC
> probably should have been considered a large enough overhaul to warrant
> 7.0, no?

Maybe so.  What's in a name, anyway?  But I think we've established a
precedent that it takes a really significant jump to bump the front
number.  If we didn't call MVCC 7.0, the stuff we currently have
ready-to-go doesn't seem to justify it either.  I think what we have
in current sources is a nice maintenance update, or maybe a little more
than that if Jan has a good chunk of foreign-key stuff working.  It's
worth getting it out to users --- but it doesn't feel like a "7.0"
to me.

OTOH, we've already changed the version ID in current sources, and
changing it back might not be worth the trouble of arguing ;-)

			regards, tom lane

Fri, 10 Dec 1999 03:06:16 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.6 release 
On Fri, 10 Dec 1999, The Hermit Hacker wrote:

> Here's a question...should we beta on Feb 1st but make it 7.0?  If we are
> going to be looking for a "long slog" for 7, why not "freeze" things on
> Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> 
> Like, what point do we call things a major release?  In a sense, MVCC
> probably should have been considered a large enough overhaul to warrant
> 7.0, no?

I thought Marc decided[1] last year to drop the minor.minor version
numbers.  IOW, there would be no 6.6.1, 6.6.2, etc.  Make the upcoming
release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
when WAL and the other stuff is ready - or as it's ready - release 8.0
and fix any glitches as 8.1, etc.  Currently every minor release is really
a major one, so why not just mark it as such and not worry about it?

Vince.

[1] Or did you do that on inn-workers and not here?  It was about the same
time FreeBSD dropped the major.minor.minor for the major.minor numbering.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Fri, 10 Dec 1999 06:38:48 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] 6.6 release 
Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems foreign key ability would be enough to justify a 6.6.
>
> Even without foreign keys, we have enough bugfixes in place to justify
> a 6.6 release, I think.  If Jan can get some amount of foreign key
> support working before Feb, that'd be a nice bonus --- but it's not
> really necessary.

    As  far  as  I  see it now, I can get the FK stuff with MATCH
    FULL ready by February first. Must be enough.


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) #



Fri, 10 Dec 1999 13:38:49 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] 6.6 release
On Fri, 10 Dec 1999, Tom Lane wrote:

> Maybe so.  What's in a name, anyway?  But I think we've established a
> precedent that it takes a really significant jump to bump the front

Actually, we've never set a precedent...v6.0 was so named more because
v1.10 just sounded like such a small number compared to the overall age of
the software...

> OTOH, we've already changed the version ID in current sources, and
> changing it back might not be worth the trouble of arguing ;-)

Okay, I can agree with that one :)

Peter brought up a good argument over on his side too...make the Feb1st
one 7, and we'll make the post-WAL stuff 8.0 ...

Just as a note, I'm not 100% certain how this generally works in "real
life", but, in some circumstances, I've seen it happen where the major
gets bumped a significant number of changes have gone into everything
since the last major bump...I think we have achieved that at least one
release back...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 10 Dec 1999 08:42:41 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.6 release 
On Fri, 10 Dec 1999, Vince Vielhaber wrote:

> On Fri, 10 Dec 1999, The Hermit Hacker wrote:
> 
> > Here's a question...should we beta on Feb 1st but make it 7.0?  If we are
> > going to be looking for a "long slog" for 7, why not "freeze" things on
> > Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> > 
> > Like, what point do we call things a major release?  In a sense, MVCC
> > probably should have been considered a large enough overhaul to warrant
> > 7.0, no?
> 
> I thought Marc decided[1] last year to drop the minor.minor version
> numbers.  IOW, there would be no 6.6.1, 6.6.2, etc.  Make the upcoming
> release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
> when WAL and the other stuff is ready - or as it's ready - release 8.0
> and fix any glitches as 8.1, etc.  Currently every minor release is really
> a major one, so why not just mark it as such and not worry about it?
> 
> Vince.
> 
> [1] Or did you do that on inn-workers and not here?  It was about the same
> time FreeBSD dropped the major.minor.minor for the major.minor numbering.

Would have been here...

The problem, as I see it, is that the FreeBSD camp is more "strict" in how
it does their source tree...there is a development tree (X.y), and a
stable tree (X-1.y)...if something is back-patchable to X-1.y from X.y, it
gets done (ie. bug fixes, security fixes or even feature changes *as long
as* they don't change the API...

We're about 50% there, but not completely...this last release (6.5) has
been fantastic...ppl have been back-patching to the 6.5 tree, providing us
wiht interim releases, but not to the level that we can build a 6.6 off
that tree...

when we do up Release 7, which I'd like to make this one, I'd *love* to
make this a whole-hog thing...tag/branch things as REL_7, no minor
number...then its up to the developers to decide whether something is
back-patchable (like they've been doing up until now) with a periodic
release put out while Release 8 is being worked on.

It slows down the rush of getting a full release out while allowign ppl
access to the debug'd advances in the upcoming release...


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 10 Dec 1999 08:56:30 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.6 release 
Thus spake Jan Wieck
>     As  far  as  I  see it now, I can get the FK stuff with MATCH
>     FULL ready by February first. Must be enough.

Any chance of getting the FK semantics into the parser right away even
though it is ignored?  As soon as it is there we can start modifying
our CREATE TABLE scripts in preparation for when the underlying code
is there.

Hmm.  Sounds like an argument I had with Jolly once over PKs.  :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Fri, 10 Dec 1999 08:58:42 -0500 (EST)
"D'Arcy" "J.M." Cain <darcy@druid.net>
Re: [HACKERS] 6.6 release
wieck@debis.com (Jan Wieck) writes:
>>>> Seems foreign key ability would be enough to justify a 6.6.
>> 
>> Even without foreign keys, we have enough bugfixes in place to justify
>> a 6.6 release, I think.

>     As  far  as  I  see it now, I can get the FK stuff with MATCH
>     FULL ready by February first. Must be enough.

If we need another feature to "justify" a release, I think I just
figured out how to do "COUNT(DISTINCT x)" with only maybe a day's work.
Watch this space...

			regards, tom lane

Fri, 10 Dec 1999 09:59:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.6 release 
Marc G. Fournier wrote:

> when we do up Release 7, which I'd like to make this one, I'd *love* to
> make this a whole-hog thing...tag/branch things as REL_7, no minor
> number...then its up to the developers to decide whether something is
> back-patchable (like they've been doing up until now) with a periodic
> release put out while Release 8 is being worked on.

    I  would really appreceate that. Maybe we need to go ahead in
    this manner and make more use of CVS branching.

    We have long standing TODO items, which require  co  work  of
    multiple  developers, affect alot of the code and will take a
    long time to implement. Tuple split, fmgr redesign, parsetree
    overhaul to name some.

    Especially  the  fact  that  noone  can  do  them  alone IMHO
    requires to have a separate branch,  where  the  sources  can
    stay  broken  for  some  time.   For example if we change the
    parsetree representation, we first change the parser and look
    at  the  printed  output's  until  it  fits. Then work on the
    planner to get them running and parallel enhance the rewriter
    to  integrate  it  again.  During  this time, the parser will
    generate things that may make the entire system unusable,  so
    any other development would get stuck.

    I  don't think that all problems could be tackled at once. My
    idea is to analyze one  of  these  problems  in  depth,  then
    branch off and have the developers, required to get this item
    done, doing it separated there. The final result  will  be  a
    patch  based  on  an older release, that requires some manual
    work to get it merged into the current tree, of course.   The
    benefit  would  be, that this long term development would not
    be interfered by CURRENT improvements, nor will it delay  any
    subsequent releasing of funny, neat things.

    Just an idea.


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) #



Fri, 10 Dec 1999 16:03:27 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] 6.6 release
The Hermit Hacker <scrappy@hub.org> writes:
> On Fri, 10 Dec 1999, Vince Vielhaber wrote:
>> I thought Marc decided[1] last year to drop the minor.minor version
>> numbers.  IOW, there would be no 6.6.1, 6.6.2, etc.  Make the upcoming
>> release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
>> when WAL and the other stuff is ready - or as it's ready - release 8.0
>> and fix any glitches as 8.1, etc.  Currently every minor release is really
>> a major one, so why not just mark it as such and not worry about it?

> when we do up Release 7, which I'd like to make this one, I'd *love* to
> make this a whole-hog thing...tag/branch things as REL_7, no minor
> number...

Yeah, I was thinking that if we were to call this 7.0 and have plans
for going to 8.0 as soon as WAL &etc are done, then we'd basically be
dropping one level of version number --- no need for a third number
if major revs are that close together.  That's OK with me as long as
we all understand that it's a change in naming practices.  There are
things we'd need to change to make it work.  For example, PG_VERSION
would need to record only the top version number: 7.0 and 7.1 would be
expected to have compatible databases, not incompatible ones.

			regards, tom lane

Fri, 10 Dec 1999 10:06:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.6 release 
>
> Thus spake Jan Wieck
> >     As  far  as  I  see it now, I can get the FK stuff with MATCH
> >     FULL ready by February first. Must be enough.
>
> Any chance of getting the FK semantics into the parser right away even
> though it is ignored?  As soon as it is there we can start modifying
> our CREATE TABLE scripts in preparation for when the underlying code
> is there.
>
> Hmm.  Sounds like an argument I had with Jolly once over PKs.  :-)

    The  current  source  tree  only  lacks  the  parsers part to
    specify

        INITIALLY DEFERRED|IMMEDIATE
        [ NOT ] DEFERRABLE

    in a columns REFERENCES clause. They are fully supported in a
    tables CONSTRAINT clause.

    All  the  functionality  for MATCH FULL is there too already.
    Though, it's not well tested up to now, but that's  not  your
    problem I assume.


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) #



Fri, 10 Dec 1999 16:11:56 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] 6.6 release
> So we'd be looking at Beta on Feb 1st, with a release around Apr 1st, and
> beta for 7 being around June 1st, with 7 release for Sept 1st?

I don't see why we couldn't plan on a Mar 1 final, with the assumption
that the beta will take one month.  It may take longer, but it may not.

> 
> IMHO, 7 is waiting for Vadim/WAL...we're doing a 6.6 due to him being
> indisposed until Mar/Apr, correct?

Not really.  We have some big items open, but they are not very far
along, except WAL, and because he can't finish for a while, it makes
sense to release what we have done for the past six months.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 10 Dec 1999 11:21:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 6.6 release
> I thought Marc decided[1] last year to drop the minor.minor version
> numbers.  IOW, there would be no 6.6.1, 6.6.2, etc.  Make the upcoming
> release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
> when WAL and the other stuff is ready - or as it's ready - release 8.0
> and fix any glitches as 8.1, etc.  Currently every minor release is really
> a major one, so why not just mark it as such and not worry about it?
> 
> Vince.
> 
> [1] Or did you do that on inn-workers and not here?  It was about the same
> time FreeBSD dropped the major.minor.minor for the major.minor numbering.

I don't think it was here.  I never heard about it.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 10 Dec 1999 11:38:42 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 6.6 release
> Tom Lane wrote:
> 
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Seems foreign key ability would be enough to justify a 6.6.
> >
> > Even without foreign keys, we have enough bugfixes in place to justify
> > a 6.6 release, I think.  If Jan can get some amount of foreign key
> > support working before Feb, that'd be a nice bonus --- but it's not
> > really necessary.
> 
>     As  far  as  I  see it now, I can get the FK stuff with MATCH
>     FULL ready by February first. Must be enough.

Foreign key is quite complicated.  It will take them a while even to ask
for more than that.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 10 Dec 1999 11:39:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 6.6 release
> Yeah, I was thinking that if we were to call this 7.0 and have plans
> for going to 8.0 as soon as WAL &etc are done, then we'd basically be
> dropping one level of version number --- no need for a third number
> if major revs are that close together.  That's OK with me as long as
> we all understand that it's a change in naming practices.  There are
> things we'd need to change to make it work.  For example, PG_VERSION
> would need to record only the top version number: 7.0 and 7.1 would be
> expected to have compatible databases, not incompatible ones.

Makes sense in that our 6.4->6.5 release is really a major release for
other people, but if we go to the new naming, we are going to get > 10
very soon, and we will start looking like GNU Emacs at version 19 or 20.

We are guilty of our own success in making such big releases.

I vote we keep it the same.  Our users already know every release is a
major one, and very high release numbers > 10 look kind of strange to
me.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 10 Dec 1999 11:46:38 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 6.6 release
On Fri, 10 Dec 1999, Bruce Momjian wrote:

> Makes sense in that our 6.4->6.5 release is really a major release for
> other people, but if we go to the new naming, we are going to get > 10
> very soon, and we will start looking like GNU Emacs at version 19 or 20.

The other problem is that if we keep going with 6.5->6.6->6.x, we're gonna
hit 6.10, etc...looks funnier, IMHO...and, unless something major comes
along after WAL and all that, never go beyond 7? :)

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 10 Dec 1999 12:56:19 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.6 release
> The other problem is that if we keep going with 6.5->6.6->6.x, we're gonna
> hit 6.10, etc...looks funnier, IMHO...and, unless something major comes
> along after WAL and all that, never go beyond 7? :)

v8.0: Corba, or XML, or one of those IBM standard protocol things for
fe/be
v9.0: multiple database access
v10.0: distributed databases
v11.0: features released as M$Postgres-1.0 after M$ owns every ISP
scrappy could use, cuts off access, and takes over the sources

;) :)))

                       - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Fri, 10 Dec 1999 17:26:59 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] 6.6 release
"D'Arcy J.M. Cain" wrote:
> 
> Thus spake Jan Wieck
> >     As  far  as  I  see it now, I can get the FK stuff with MATCH
> >     FULL ready by February first. Must be enough.
> 
> Any chance of getting the FK semantics into the parser right away even
> though it is ignored?

We do have foreign key syntax in parser

hannu=> create table foreign_tab(
hannu->   f int,
hannu->   foreign key(f) references primary_tab (i)
hannu-> );
NOTICE:  CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented

What do you mean by semantics here ? 
Should it check that the primary table and field(s) exist ?

------------------
Hannu

Sat, 11 Dec 1999 11:28:02 +0200
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] 6.6 release
Thus spake Hannu Krosing
> "D'Arcy J.M. Cain" wrote:
> > Any chance of getting the FK semantics into the parser right away even
> > though it is ignored?
> 
> We do have foreign key syntax in parser
> 
> hannu=> create table foreign_tab(
> hannu->   f int,
> hannu->   foreign key(f) references primary_tab (i)
> hannu-> );
> NOTICE:  CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented
> 
> What do you mean by semantics here ? 
> Should it check that the primary table and field(s) exist ?

Nope.  That's exactly what I meant.  I didn't realize that it was already
there.  Sorry for the confusion.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Sat, 11 Dec 1999 07:48:43 -0500 (EST)
"D'Arcy" "J.M." Cain <darcy@druid.net>
Re: [HACKERS] 6.6 release
>
> Thus spake Hannu Krosing
> > "D'Arcy J.M. Cain" wrote:
> > > Any chance of getting the FK semantics into the parser right away even
> > > though it is ignored?
> >
> > We do have foreign key syntax in parser
> >
> > hannu=> create table foreign_tab(
> > hannu->   f int,
> > hannu->   foreign key(f) references primary_tab (i)
> > hannu-> );
> > NOTICE:  CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented
> >
> > What do you mean by semantics here ?
> > Should it check that the primary table and field(s) exist ?
>
> Nope.  That's exactly what I meant.  I didn't realize that it was already
> there.  Sorry for the confusion.

Caution D'Arcy,

    the  FOREIGN KEY syntax that's in 6.5 is a little incomplete.
    Doesn't   allow   match   type   and   constraint   attribute
    specification  (deferrability  and  initial  deferred state).
    Especially the match type is required, because  in  7.0  only
    MATCH   FULL  will  be  implemented,  not  the  <unspecified>
    default.

    As I said in another post, the  constraint  attr  spec  isn't
    possible  in  column  constraint  right now in 7.0, but we're
    working on it.  Should be ready in a few days.


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) #



Sat, 11 Dec 1999 14:39:02 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] 6.6 release