Tom Lane wrote:
Actually, I think any attempt to do that would result in a fork,
and a consequent splintering of the community. We can get away
Perhaps the answer might be a pre-emptive simplifying fork to postgres-NG,
perhaps taking a lead from MySQL and Samba.
I'm not sure that you would
David Fetter writes:
> This isn't about a "passion for neatness." It's about recognizing
> that some experiments have failed and weeding out the failures. The
> RULE system, for example, was a ground-breaking innovation in the
> sense of being a truly new idea. Evidence over the decades since h
On Tue, Oct 20, 2009 at 11:48 AM, David Fetter wrote:
> On Tue, Oct 20, 2009 at 10:46:10AM -0400, Andrew Dunstan wrote:
>> Robert Haas wrote:
>>> I think the real issue, though, is that answer to Ron's original
>>> question is "No". When backward compatibility gets in the way of
>>> cool new feat
On Tue, Oct 20, 2009 at 10:46:10AM -0400, Andrew Dunstan wrote:
> Robert Haas wrote:
>> I think the real issue, though, is that answer to Ron's original
>> question is "No". When backward compatibility gets in the way of
>> cool new features, that's worth considering. But removing backward
>> com
"Greg Sabino Mullane" writes:
> That particular example is a very poor one for illustrating your
> point. You severely underestimate "get away with" for the implicit
> cast changes in 8.3. This was a really big deal for many, many users
> of Postgres, and continues to cause many problems to this d
Robert Haas wrote:
I think the real issue, though, is that answer
to Ron's original question is "No". When backward compatibility gets
in the way of cool new features, that's worth considering. But
removing backward compatibility just for the sake of removing backward
compatibility doesn't r
"Greg Sabino Mullane" writes:
> I'm sure the casting changes broke more applications and prevented more
> people from upgrading than every thing on Ron's list for a clean 9.0 would.
> Not that I'm necessarily promoting his idea, but 8.3 was already a
> "all-at-once breakage" release.
I'm having t
On Tue, Oct 20, 2009 at 10:07 AM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Tom Lane replied to Ron Mayer:
>>> Would postgres get considerably cleaner if a hypothetical 9.0 release
>>> skipped backward compatibility and removed anything that's only
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied to Ron Mayer:
>> Would postgres get considerably cleaner if a hypothetical 9.0 release
>> skipped backward compatibility and removed anything that's o
Aidan Van Dyk wrote:
> * Tom Lane [091019 18:45]:
>> Actually, I think any attempt to do that would result in a fork,
>> and a consequent splintering of the community. We can get away
>> with occasionally cleaning up individual problematic behaviors
>> (example: implicit casts to text), but any s
On Mon, 2009-10-19 at 14:08 -0700, Ron Mayer wrote:
> Tom Lane wrote:
> > What are the probabilities that the OpenACSes of the world will just
> > set the value to "backward compatible" instead of touching their code?
>
> Would postgres get considerably cleaner if a hypothetical 9.0 release
> skip
"Marc G. Fournier" writes:
> Just curious, but with that thought in mind, are we doing any code
> cleanups as far as EOL releases? Ie. is there any code in our tree right
> now that is for 'backward compatibility' for 7.3.x versions that could be
> cleaned out?
Well, we were just trying to pu
On Mon, 19 Oct 2009, Tom Lane wrote:
Ron Mayer writes:
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
maintained for historical reasons?
Yeah, and our user community would get a lot smaller too :-(
Actual
* Tom Lane [091019 18:45]:
> Ron Mayer writes:
> > Would postgres get considerably cleaner if a hypothetical 9.0 release
> > skipped backward compatibility and removed anything that's only
> > maintained for historical reasons?
>
> Yeah, and our user community would get a lot smaller too :-(
>
Ron Mayer writes:
> Would postgres get considerably cleaner if a hypothetical 9.0 release
> skipped backward compatibility and removed anything that's only
> maintained for historical reasons?
Yeah, and our user community would get a lot smaller too :-(
Actually, I think any attempt to do that w
Tom Lane wrote:
> What are the probabilities that the OpenACSes of the world will just
> set the value to "backward compatible" instead of touching their code?
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
main
16 matches
Mail list logo
