On Fri, Jun 22, 2012 at 9:30 PM, Josh Berkus <josh@agliodbs.com> wrote:
> http://pgolub.wordpress.com/2012/06/22/backward-compatibility-never-heard-of-it
>
> If we had stable system views for all database objects (stable as in we
> just append to them), then refactoring our system tables wouldn't break
> things for our users. Just sayin'.
This has been discussed before, and I'm still not buying it. I mean,
suppose you wrote code that depended on anything stated in a
constraint always being true. Then we added deferrable constraints.
Oops. But would you rather NOT have that feature? Appending columns
doesn't help in that case.
Or suppose you wrote code that depended on
pg_stat_user_functions.total_time being an integer. Well, we could
append a new column with a different datatype, but now you've got two
columns with the same information, which is a confusing mess.
I still remember the first time my application code got broken by a
system catalog change. Some moron added pg_attribute.attisdropped,
and boy was I annoyed. However, in between my annoyance, I realized
that (1) adapting my code wasn't really going to be that hard and (2)
being able to drop columns was a pretty good feature. Granted, a
compatibility view would have worked in this case, but only if I'd
been using the compatibility view rather than the underlying table,
and I am not sure I would have been that smart.
The compatibility breaks that really bother me are the ones that
affect a lot of people: standard_conforming_strings, 8.3's implicit
casting changes, and Tom's PL/plgsql lexer stuff that made a bunch of
things no longer usable as unquoted variable names. That stuff breaks
application code, sometimes quite a lot of it. System catalog changes
have a pretty small impact by comparison, although of course (as in
this case) it's not perfect.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company