Re: Could postgres be much cleaner if a future release skipped backward compatibility?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Дата
Msg-id 1710.1256056031@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Could postgres be much cleaner if a future release skipped backward compatibility?  (David Fetter <david@fetter.org>)
Список pgsql-hackers
David Fetter <david@fetter.org> 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 has
> shown that it was a *bad* idea, and I like to think we're going with
> an evidence-based approach.  Things like add_missing_from and
> regex_flavor, to name two examples, are just bletcherous hacks
> invented to solve no-longer-extant problems.

The above examples seem to me to show that your argument is nonsense.
regex_flavor, in particular, is not about "failed experiments",
it's about backwards compatibility with a previous version that simply
worked differently.  It might be that we can have a sunset provision for
backwards compatibility, but to argue that it's not important pretty
much flies in the face of most of the discussions we've had on the
topic.

I agree that the RULE system is a failed experiment and we need to find
something better, but we're unlikely to rip that out either until the
replacement has been in use for a few releases.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: OpenACS vs Postgres
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution