Josh Berkus <j...@agliodbs.com> writes:
> ... I think it should.
> It'll break some extensions, so we should warn people about it more
> prominently. Robert's text lower down in the release notes is fine,
> but we should put a more prominent warning at the top with the other
> backwards compatibility breakage.
I don't think so. It's always been the case that the compatibility
warnings section considers only SQL-level incompatibilities, and if you
have C code to maintain you'd better go read the "Source Code" changes.
This isn't even a particularly large or difficult-to-deal-with change,
nor is there any chance that it will get overlooked (since your code won't
compile). So I don't think it deserves more pride of place than similar
issues have gotten in prior cycles.
As examples, consider these 9.3 "Source Code" items:
* Remove typedefs for int2/int4 as they are better represented as
int16/int32 (Peter Eisentraut)
* Use a 64-bit integer to represent WAL positions (XLogRecPtr) instead of
two 32-bit integers (Heikki Linnakangas)
Generally, tools that need to read the WAL format will need to be adjusted.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
