Обсуждение: Should next release by 8.0 (Was: Re: [GENERAL] I am being interviewed by OReilly )
Should next release by 8.0 (Was: Re: [GENERAL] I am being interviewed by OReilly )
От
"Marc G. Fournier"
Дата:
On Thu, 4 Jul 2002, Tom Lane wrote: > You could make a fair argument that the upcoming 7.3 ought to be called > 8.0, because the addition of schema support will break an awful lot of > client-side code ;-). But I doubt we will do that. Actually, from reading that thread, I started to think along those lines too ... it is a major change, is there a reason why going to 8.0 on this one is a bad idea? I realize that its *only* been 2 years that we've been in v7.0 ... :) v7.0 was released back in Mar of 2000 ... so its almost 2.5 years ... I don't necessarily agree with Bruce's thought that distributed replication would be the marker, since there is no set path to that right now, nor is there, I believe, enough knowledge about whether or not bring such in will affect anyting other then the backend itself ... With this next release, we are looking at breaking the front-end apps, as I understand it ... I think that's pretty drastic of a change to force going to 8.0 ... We don't release fast, or often, so our v7.2 is like some other projects v7.26, at the rate some of them release ... I'd like to see this next release go to 8.0 ...
> With this next release, we are looking at breaking the front-end apps, as > I understand it ... I think that's pretty drastic of a change to force > going to 8.0 ... > > We don't release fast, or often, so our v7.2 is like some other projects > v7.26, at the rate some of them release ... > > I'd like to see this next release go to 8.0 ... Hmmm...makes sense. I'd be for it. BTW - has anyone looked at Neil's PREPARE patch yet? Chris
"Marc G. Fournier" wrote: > > On Thu, 4 Jul 2002, Tom Lane wrote: > <snip> We can also go any number in between... like "7.5"... :) Regards and best wishes, Justin Clift > I'd like to see this next release go to 8.0 ... > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
While there are big changes between 7.2 and the next release, they aren't really any bigger than others during the 7.x series. I don't really feel that the next release is worth an 8.0 rather than a 7.3. But this is just an opinion; it's not something I'm prepared to argue about. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
In my book, schema support is a big thing, leading to rethink a lot of database organization and such. PostgreSQL 8 would stress this importance. -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
On Fri, 5 Jul 2002, Curt Sampson wrote: > > While there are big changes between 7.2 and the next release, they > aren't really any bigger than others during the 7.x series. I don't > really feel that the next release is worth an 8.0 rather than a 7.3. But > this is just an opinion; it's not something I'm prepared to argue about. Actually, the "big" change is such that will, at least as far as I'm understanding it, break pretty much every front-end applicaiton ... which, I'm guessing, is pretty major, no? :)
"Marc G. Fournier" <scrappy@hub.org> writes:
> Actually, the "big" change is such that will, at least as far as I'm
> understanding it, break pretty much every front-end applicaiton ...
Only those that inspect system catalogs --- I'm not sure what percentage
that is, but surely it's not "pretty much every" one. psql for example
is only affected because of its \d commands.
regards, tom lane
On Fri, 5 Jul 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > Actually, the "big" change is such that will, at least as far as I'm > > understanding it, break pretty much every front-end applicaiton ... > > Only those that inspect system catalogs --- I'm not sure what percentage > that is, but surely it's not "pretty much every" one. psql for example > is only affected because of its \d commands. Okay, anyone have any ideas of other packages that would inspect the system catalog? The only ones I could think of, off the top of my head, would be pgAccess, pgAdmin and phpPgAdmin ... but I would guess that any 'administratively oriented' interface would face similar problems, no?
> Actually, the "big" change is such that will, at least as far as I'm
> understanding it, break pretty much every front-end applicaiton ... which,
> I'm guessing, is pretty major, no? :)
I've always thought of our release numbering as having "themes". The 6.x
series took Postgres from interesting but buggy to a solid system, with
a clear path to additional capabilities. The 7.x series fleshes out SQL
standards compliance and rationalizes the O-R features, as well as adds
to robustness and speed with WAL etc. And the 8.x series would enable
Postgres to extend to distributed systems etc., quite likely having some
fundamental restructuring of the way we handle sources of data (remember
our discussions a couple years ago regarding "tuple sources"?).
So I feel that bumping to 8.x just for schemas is not necessary. I
*like* the idea of having more than one or two releases in a series, and
would be very happy to see a 7.3 released.
- Thomas
On Fri, 5 Jul 2002, Thomas Lockhart wrote: > > Actually, the "big" change is such that will, at least as far as I'm > > understanding it, break pretty much every front-end applicaiton ... which, > > I'm guessing, is pretty major, no? :) > > I've always thought of our release numbering as having "themes". The 6.x > series took Postgres from interesting but buggy to a solid system, with > a clear path to additional capabilities. The 7.x series fleshes out SQL > standards compliance and rationalizes the O-R features, as well as adds > to robustness and speed with WAL etc. And the 8.x series would enable > Postgres to extend to distributed systems etc., quite likely having some > fundamental restructuring of the way we handle sources of data (remember > our discussions a couple years ago regarding "tuple sources"?). > > So I feel that bumping to 8.x just for schemas is not necessary. I > *like* the idea of having more than one or two releases in a series, and > would be very happy to see a 7.3 released. Seems I'm the only one for 8.x, so 7.3 it is :)
Marc G. Fournier wrote: > On Fri, 5 Jul 2002, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@hub.org> writes: > > > Actually, the "big" change is such that will, at least as far as I'm > > > understanding it, break pretty much every front-end applicaiton ... > > > > Only those that inspect system catalogs --- I'm not sure what percentage > > that is, but surely it's not "pretty much every" one. psql for example > > is only affected because of its \d commands. > > Okay, anyone have any ideas of other packages that would inspect the > system catalog? The only ones I could think of, off the top of my head, > would be pgAccess, pgAdmin and phpPgAdmin ... but I would guess that any > 'administratively oriented' interface would face similar problems, no? That's a good point. Only the admin stuff is affected, not all applications. All applications _can_ now use schemas, but for most cases applications remain working unchanged. -- Bruce Momjian | http://candle.pha.pa.us pgman@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 July 5, 2002 10:27 am, Marc G. Fournier wrote:
> On Fri, 5 Jul 2002, Tom Lane wrote:
> > "Marc G. Fournier" <scrappy@hub.org> writes:
> > > Actually, the "big" change is such that will, at least as far as I'm
> > > understanding it, break pretty much every front-end applicaiton ...
> >
> > Only those that inspect system catalogs --- I'm not sure what percentage
> > that is, but surely it's not "pretty much every" one. psql for example
> > is only affected because of its \d commands.
>
> Okay, anyone have any ideas of other packages that would inspect the
> system catalog? The only ones I could think of, off the top of my head,
> would be pgAccess, pgAdmin and phpPgAdmin ... but I would guess that any
> 'administratively oriented' interface would face similar problems, no?
PyGreSQL pokes into the catalogues a bit.
--
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.
Hi! > I've always thought of our release numbering as having "themes". The 6.x > series took Postgres from interesting but buggy to a solid system, with > a clear path to additional capabilities. The 7.x series fleshes out SQL > standards compliance and rationalizes the O-R features, as well as adds > to robustness and speed with WAL etc. And the 8.x series would enable > Postgres to extend to distributed systems etc. This sounds very good to me. I get the feeling sometimes that software projects just increase the major version number to 'sound interesting'. I don't think that PostgreSQL needs that anymore. A modest numbering policy might even give it a 'stable' feeling... Sander.