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.)
Advertising
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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
