Thread: Features for next release
Hmm. I see a problem coming up for myself :(
I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for
the next release. That will take a lot of time afaik. We also have
lots of great new features (almost certainly) coming up, such as WAL
and RI. Lots of stuff, and taken together it should lead to a v7.0
release.
However! I've been waiting for v7.0 to do internal remapping of the
datetime types (and possibly other types; I'm not remembering right
now) so that the 4-byte TIMESTAMP becomes, internally, what is
currently DATETIME and so that the current DATETIME becomes a synonym
for TIMESTAMP. If we are releasing v7.0 rather than v6.6, then I
should work on that now to ensure it is completed. If we might release
as v6.6, I should continue to work on OUTER JOIN, since the type
changes shouldn't go in yet.
Any opinions/comments on the right path to take? With code changes and
docs changes I would think that the datetime stuff is two or a few
weeks work with my off-work time, which I suppose wouldn't impace a
release schedule too much...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart wrote:
>
> Hmm. I see a problem coming up for myself :(
>
> I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for
> the next release. That will take a lot of time afaik. We also have
> lots of great new features (almost certainly) coming up, such as WAL
> and RI. Lots of stuff, and taken together it should lead to a v7.0
> release.
What I actually see when starting/stopping the postmaster
lets me think that Vadim alread has the WAL target in sight.
And for RI I can say that we'll have at least FOREIGN KEY for
MATCH FULL without PENDANT in the next release. The key
features are in place and there's plenty of time left to do
all the stuff around.
>
> However! I've been waiting for v7.0 to do internal remapping of the
> datetime types (and possibly other types; I'm not remembering right
> now) so that the 4-byte TIMESTAMP becomes, internally, what is
> currently DATETIME and so that the current DATETIME becomes a synonym
> for TIMESTAMP. If we are releasing v7.0 rather than v6.6, then I
> should work on that now to ensure it is completed. If we might release
> as v6.6, I should continue to work on OUTER JOIN, since the type
> changes shouldn't go in yet.
>
> Any opinions/comments on the right path to take? With code changes and
> docs changes I would think that the datetime stuff is two or a few
> weeks work with my off-work time, which I suppose wouldn't impace a
> release schedule too much...
Break TIMESTAMP right now. IMHO it would be THE reason (a
functional incompatibility to v6.5) we where looking for to
be 100% sure the next release must be v7.0.
I clearly vote for v7.0 - even if I personally hoped we would
have a little chance to produce the ultimate devils
PostgreSQL-v6.6.6 someday.
Apropos devil: tomorrow Braunschweig Lions vs. Hamburg Blue
Devils here in Hamburg - German bowl! Go Devils go!
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) #
> Hmm. I see a problem coming up for myself :( > > I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for > the next release. That will take a lot of time afaik. We also have > lots of great new features (almost certainly) coming up, such as WAL > and RI. Lots of stuff, and taken together it should lead to a v7.0 > release. > > However! I've been waiting for v7.0 to do internal remapping of the > datetime types (and possibly other types; I'm not remembering right > now) so that the 4-byte TIMESTAMP becomes, internally, what is > currently DATETIME and so that the current DATETIME becomes a synonym > for TIMESTAMP. If we are releasing v7.0 rather than v6.6, then I > should work on that now to ensure it is completed. If we might release > as v6.6, I should continue to work on OUTER JOIN, since the type > changes shouldn't go in yet. > > Any opinions/comments on the right path to take? With code changes and > docs changes I would think that the datetime stuff is two or a few > weeks work with my off-work time, which I suppose wouldn't impace a > release schedule too much... My guess is 7.0. With the minor releases still being made, Marc is in no rush. -- 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, Pennsylvania19026
> Thomas Lockhart wrote: > > > > > Hmm. I see a problem coming up for myself :( > > > > I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for > > the next release. That will take a lot of time afaik. We also have > > lots of great new features (almost certainly) coming up, such as WAL > > and RI. Lots of stuff, and taken together it should lead to a v7.0 > > release. > > What I actually see when starting/stopping the postmaster > lets me think that Vadim alread has the WAL target in sight. Yes, looks very impressive:DEBUG: Data Base System is starting up at Fri Oct 8 01:38:04 1999DEBUG: Data Base System wasshutdowned at Fri Oct 8 01:37:42 1999DEBUG: CheckPoint record at (0, 968)DEBUG: Redo record at (0, 968); Undo recordat (0, 0)DEBUG: NextTransactionId: 20995; NextOid: 0DEBUG: Invalid NextTransactionId/NextOidDEBUG: Data Base Systemis in production state at Fri Oct 8 01:38:04 1999 -- 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, Pennsylvania19026
On Fri, Oct 08, 1999 at 06:25:50PM +0200, Jan Wieck wrote: > I clearly vote for v7.0 - even if I personally hoped we would Me too. Although it means I have to check whether there is more stuff I have to add to ECPG before 7.0 comes out. > have a little chance to produce the ultimate devils > PostgreSQL-v6.6.6 someday. It seems we are too superstitous to allow this number. :-) > Apropos devil: tomorrow Braunschweig Lions vs. Hamburg Blue > Devils here in Hamburg - German bowl! Go Devils go! Jan, now you surprise me. You are a football fan? I never expected another German on this list to love football (american style that is). Maybe we are able to meet at a football games. But then I cannot come to the German Bowl. Do you go to NFLE games too? Michael P.S.: Sorry for being off-topic for this list in the last part of my mail. -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
It seems people are thinking winter or early spring (northern hemisphere
that is ;-)) for the next major release, and by then I think there will
be enough cool stuff done that we can call it 7.0. The only really big
to-do item that no one seems to be committed to doing in this cycle is
tuples bigger than a disk block, and maybe once the dust settles for
long queries someone will feel like tackling that...
I have another reason for calling it 7.0, which is that if we fix
the function-call interface the way I want to, we will break existing
user-written loadable modules that contain C-language functions.
Better to do that in a "7.0" than in a "6.6", no?
regards, tom lane
On Fri, 8 Oct 1999, Tom Lane wrote:
> It seems people are thinking winter or early spring (northern hemisphere
> that is ;-)) for the next major release, and by then I think there will
> be enough cool stuff done that we can call it 7.0. The only really big
> to-do item that no one seems to be committed to doing in this cycle is
> tuples bigger than a disk block, and maybe once the dust settles for
> long queries someone will feel like tackling that...
>
> I have another reason for calling it 7.0, which is that if we fix
> the function-call interface the way I want to, we will break existing
> user-written loadable modules that contain C-language functions.
> Better to do that in a "7.0" than in a "6.6", no?
Based on all the comments flyng around, v7.0 it is. to be released...some
day :)
Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > I have another reason for calling it 7.0, which is that if we fix > > the function-call interface the way I want to, we will break existing > > user-written loadable modules that contain C-language functions. > > Better to do that in a "7.0" than in a "6.6", no? > > Based on all the comments flyng around, v7.0 it is. to be released...some > day :) > > Bruce, you asked for a v6.5.3 to be released...anything outstanding that > should prevent me from doing that tomorrow afternoon? Not that I know of. I was waiting to see if we could come up with other patches, but I don't think that is going to happen anytime soon. -- 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, Pennsylvania19026
>> Bruce, you asked for a v6.5.3 to be released...anything outstanding that
>> should prevent me from doing that tomorrow afternoon?
> Not that I know of. I was waiting to see if we could come up with other
> patches, but I don't think that is going to happen anytime soon.
On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.
I imagine that we will acquire a few more fixes for 6.5.* as time goes
on, and it looks like 7.0 will be months away. Maybe a 6.5.* update
every month or two (if anything's been patched) would be the way to
proceed.
regards, tom lane
> >> Bruce, you asked for a v6.5.3 to be released...anything outstanding that > >> should prevent me from doing that tomorrow afternoon? > > > Not that I know of. I was waiting to see if we could come up with other > > patches, but I don't think that is going to happen anytime soon. > > On the other hand, is there a reason to be in a rush to put out 6.5.3? > I didn't think we had many important changes from 6.5.2 yet. > > I imagine that we will acquire a few more fixes for 6.5.* as time goes > on, and it looks like 7.0 will be months away. Maybe a 6.5.* update > every month or two (if anything's been patched) would be the way to > proceed. > Missing pgaccess source code. -- 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, Pennsylvania19026
On Tue, 12 Oct 1999, Tom Lane wrote:
> >> Bruce, you asked for a v6.5.3 to be released...anything outstanding that
> >> should prevent me from doing that tomorrow afternoon?
>
> > Not that I know of. I was waiting to see if we could come up with other
> > patches, but I don't think that is going to happen anytime soon.
>
> On the other hand, is there a reason to be in a rush to put out 6.5.3?
> I didn't think we had many important changes from 6.5.2 yet.
v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Tue, 12 Oct 1999, Tom Lane wrote: > > > >> Bruce, you asked for a v6.5.3 to be released...anything outstanding that > > >> should prevent me from doing that tomorrow afternoon? > > > > > Not that I know of. I was waiting to see if we could come up with other > > > patches, but I don't think that is going to happen anytime soon. > > > > On the other hand, is there a reason to be in a rush to put out 6.5.3? > > I didn't think we had many important changes from 6.5.2 yet. > > v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :( OK, it was me, I didn't want to add it to 6.5.2 because it was not a major bugfix, I got it 24 hours before release, it was a completely new source tree layout, I asked the author to check my work, I didn't check my work, and it was not committed properly. I feel better now. :-) -- 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, Pennsylvania19026
The Hermit Hacker <scrappy@hub.org> writes:
>> On the other hand, is there a reason to be in a rush to put out 6.5.3?
>> I didn't think we had many important changes from 6.5.2 yet.
> v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :(
Ah, right, I'd forgotten that. OK, we need a 6.5.3.
It sounds like Peter wants another day to check JDBC though...
regards, tom lane
Bruce Momjian wrote: >> Bruce, you asked for a v6.5.3 to be released...anything outstanding that >> should prevent me fromdoing that tomorrow afternoon? > >Not that I know of. I was waiting to see if we could come up with other >patches,but I don't think that is going to happen anytime soon. Will this include a patch to let NUMERIC fields be indexed? -- Vote against SPAM: http://www.politik-digital.de/spam/ ======================================== Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "Blessed is the man who makes the LORD his trust, who does not look to the proud, to those who turn aside to false gods." Psalms 40:4
> Bruce Momjian wrote: > >> Bruce, you asked for a v6.5.3 to be released...anything outstanding that > >> should prevent me from doing that tomorrow afternoon? > > > >Not that I know of. I was waiting to see if we could come up with other > >patches, but I don't think that is going to happen anytime soon. > > Will this include a patch to let NUMERIC fields be indexed? Not sure. -- 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, Pennsylvania19026
>
> > Bruce Momjian wrote:
> > >> Bruce, you asked for a v6.5.3 to be released...anything outstanding that
> > >> should prevent me from doing that tomorrow afternoon?
> > >
> > >Not that I know of. I was waiting to see if we could come up with other
> > >patches, but I don't think that is going to happen anytime soon.
> >
> > Will this include a patch to let NUMERIC fields be indexed?
>
> Not sure.
Not FOR sure. Adding the default operator class etc. is
adding catalog entries. Thus it requires "initdb" and that's
a NONO for bugfix releases according to our release policy.
It's done in the v7.0 tree.
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) #