Tom Lane wrote:
> Keep in mind that if your proposal involves any serious limitation on
> the developers' freedom to refactor internal backend APIs or change
> catalog representations around, it *will be rejected*. Do not have any
> illusions on that point. It'll be a tough enough sell freezing on-disk
> representations for user data. Demanding the internal ability to read
> old catalog versions would be a large and ongoing drag on development;
> I do not think we'll hold still for it. (To point out just one of many
> problems, it'd largely destroy the C-struct-overlay technique for
> reading catalogs.)
One thing no-one's mentioned is how we're going to deal with definitive
incompatibilities.
Examples:
- Tightening of UTF8 code. Means some text from old version won't transfer.
- Changing behaviour of greatest() - recently discussed. Might
invalidate views/application queries.
It's the second example that I can see biting, the UTF stuff is big
enough that it'll be noticed. It'd be all too easy to have a change in
some inet-addr function that you don't notice your app is using. I can't
think of any way of definitively auditing what features are in use (or
have changed between versions).
Or are these examples of changes that will only be allowed e.g. every
other major version.
-- Richard Huxton Archonet Ltd