Re: Prepping to break every past release... - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Prepping to break every past release...
Date
Msg-id 874oy1sgb5.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Prepping to break every past release...  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
>>>>> "Simon" == Simon Riggs <simon@2ndQuadrant.com> writes:
>> Now, of course, counting the upcoming 8.4 there have been three>> (and a bit - the original design predates 8.1,
thoughit did>> anticipate some 8.1 features) new releases against which the>> original concept can be tested. And,
guesswhat, nothing in those>> releases has even come close to invalidating the original design>> concept (as we knew
allalong).>> >> If you're still not convinced of that fact, it would be possible>> to take the original design and
updateit to 8.4 following the>> original plan. But I'm not prepared to spend any time on this if>> the only result is
goingto be more argument.
 
Simon> I see the use for some more stable views.
Simon> Would it be better to publish them as an external project?

They already are, though they are not complete and have not been
maintained much for 8.1 and later;
http://pgfoundry.org/projects/newsysviews/
Simon> That way we can still use them for both old and new releases.

It was always expected that they would be available on pgfoundry for
use on releases prior to their inclusion in core.
Simon> Once the project takes hold it might then be included in core

Speaking purely for myself, I'm not prepared to spend any time on it
without an assurance that it will go into core if the project goals
are reasonably met.

As for Tom's opinion that this is impossible, there's an old saying:
"The one who says it cannot be done should not interrupt the one who
is doing it."
Simon> The problem with anything included in core is that weSimon> don't/can't quickly fix design flaws, so even if we
didgetSimon> something in now it might not do everything we want (and thenSimon> we'd have to change it...).
 

I'm not proposing that it go into core quickly; and certainly not
before the design is properly reviewed, criticised, whatever.

-- 
Andrew.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)
Next
From: David Fetter
Date:
Subject: Re: Prepping to break every past release...