Re: pg_class.relistemp

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_class.relistemp
Date: 2011-07-14 21:10:19
Message-ID: CA+OCxowVih-Lu7mym1toUY3nrNrxBrjiVRVavAUpCqrd1bdiCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, July 14, 2011, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> There has never, ever, been a guarantee that the system catalogs don't
>> change across versions.  Anybody issuing such queries should expect to
>> have to retest them and possibly change them in each new major release.
>
> I know that's always been our policy.  It his, however,
> vendor-unfriendly because we don't supply any interface for many things
> (such as temp tables) other than the system catalogs.
>
> So if we're going to break compatibility, then we could stand to make a
> little noise about it.

As one of said vendors, I completely disagree. 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.

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.

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2011-07-14 21:46:34 Re: Is there a committer in the house?
Previous Message Heikki Linnakangas 2011-07-14 21:10:00 Re: Understanding GIN posting trees