Re: pg_class.relistemp

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: pg_class.relistemp
Дата
Msg-id CA+OCxozF-9AC9M0qYaNHTY_RtriqXNrv_MzeZCRn3ikhFnrUbw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_class.relistemp  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Thu, Jul 14, 2011 at 10:54 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> As one of said vendors, I completely disagree.
>
> I don't agree that you qualify as a vendor.  You're on the friggin' core
> team.

And I look after the development of the leading open source management
tool for PostgreSQL, as well as a number of tools at EnterpriseDB. I
might be on the core team, but I still build tools.

> I'm talking about vendors like DBVizualizer or TORA, for which
> PostgreSQL is just one of the databases they support.  If stuff breaks
> gratuitously, the reaction of some of them is always to either drop
> support or delay it for a year or more.  This doesn't benefit our community.

I'm not talking about gratuitously breaking things - just not masking
essential changes.

>> There are a ton of
>> things that change with each release, and all we do by putting in
>> hacks for backwards compatibility is add bloat that needs to be
>> maintained, and encourage vendors to be lazy.
>
> I don't agree that having comprehensive system views with multi-version
> stability would be a "hack".

That isn't what was being suggested.

>> Break compatibility is actually something that is important to us - it
>> forces us to fix obvious issues, and makes it much harder to
>> inadvertently miss important changes.
>
> What I'm hearing from you is: "Breaking backwards compatibility is
> something we should do more of because it lets us know which vendors are
> paying attention and weeds out the unfit."   Is that what you meant to say?

No, I meant to say precisely what I did say. By not masking changes in
the catalogs, we draw attention to things that have changed for good
reason, and almost certainly need to be addressed.

> That seems like a way to ensure that PostgreSQL support continue to be
> considered optional, or based on outdated versions, for multi-database
> tools.

Whilst this particular case might be safe to just ignore in third part
tools, other changes to the catalogs are not, and masking them could
potentially hide bugs or issues that need to be fixed to actually work
properly with the newer version of the server.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Patch Review: Collect frequency statistics and selectivity estimation for arrays
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Small patch for GiST: move childoffnum to child