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
