Is PG a moving target?

From: Ken Johanson <pg-user(at)kensystem(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Is PG a moving target?
Date: 2008-02-09 17:20:51
Message-ID: 47ADE0F3.6020104@kensystem.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I acknowledge that from time to time we must accept changes in the 3rd
party software that will break our apps if we (or customers) ever
upgrade them (a compounded issue if we have heavily-used deployments in
the field and not just in-house ones to maintain).

But given the recent and dramatic example of 8.3's on-by-default
stricter typing in functions (now not-autocasting), I worry that kind of
change could happen in every minor version (8.4 etc).

Sure the strict-typing (and other compatibility-breaking changes) is a
good thing in the long run, but it discourages anyone trying to:

a) port apps from another database
b) upgrade PG to get other features, or port apps written against from a
PG version that's 1 year older

The type-strictness change, as an example, also creates pragmatic vs
academic (polarizing) debates around "rtrim(intype)" being innocuous vs
sloppy. And "database XYZ is better/worse", e.g balance of ease of use,
TCO, vs ACID, strictness etc). The word 'balance' is key.

Is there anything now, or in the works, for compatibility emulation? For
example to setup my session to act like 8.2 and allow less-strict
typing. Or can one write an app against 8.3 and safely assume that 8.4
*could* also add more behavior changes (e.g even more strict-ness in
functions where even 8.3 could be *validly argued* as being too loose)?...

Ken

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2008-02-09 17:25:19 Re: Is PG a moving target?
Previous Message Venks 2008-02-09 14:23:32 Re: Empty to NULL conversion - Ruby - Postgres ?