On 01/18/2013 04:24 AM, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 17 January 2013 16:15, Robert Haas <robertmh...@gmail.com> wrote: >>> It pains me that I've evidently failed to communicate this concept >>> clearly despite a year or more of trying. Does that make sense? Is >>> there some way I can make this more clear? The difference seems very >>> clear-cut to me, but evidently I'm not conveying it well. >> "The point", i.e. the main use case, is to replicate the DDL in a useful >> form. >> Discussions and reasoning need to focus on the main use case, not on >> weird futures or qualitative points. > I have to completely disagree with that. If we don't want PostgreSQL > to soon subside into an unfixable morass, as I think Brooks puts it, > we must *not* simply patch things in a way that expediently provides > an approximation of some desired feature. We have to consider, and put > substantial weight on, having a clean and maintainable system design. > > This is particularly the case if we're talking about a feature that > is going to expose backend internals to users to any degree. We're > either going to be constrained to not change those internals any more, > or expect to break users' applications when we do change them, and > neither result is very appealing. I actually wonder if - for now - breaking applications that use certain limited well defined features is an acceptable outcome in exchange for getting a usable first version in place. I'm approaching this from more of an end user PoV: meeting user needs with the least possible pain to users and to the Pg team.
A non-forward compatible feature wouldn't be OK to rely on in end user applications, but it'd potentially be usable (if not ideal) for things like replication tools, where practically anything is better than the current situation with DDL. They could special case their integration code by server version if they had to, adding version-specific triggers and handling code. The user application wouldn't care about the changes, they'd just need to make sure they upgraded Slony (or whatever) whenever they upgraded to a new Pg major version. I'm not suggesting that as a long term measure, but as a possible stop-gap that'd: - Allow replication to start using these features now, so they'd be ready and more mature when the final version is available; and - Permit prototyping of applications to use the new replication features What I'm thinking about is packaging the client interface in an extension that's explicitly documented as not cross-version compatible and that must be explicitly loaded by named version in order to get the feature. This would require a function-like interface for setup; if that's not possible, an alternative might be a GUC that must be explicitly set in postgresql.conf (only, not via SET) like "enable_non_forward_compatible_features" or "enable_experimental_features". I suspect that if this feature goes in, even in an ugly form, it'll help guide the development of a final version concurrently with the cleanups and refactoring that appears to be necessary. Note that non-forward-compatible changes have been made repeatedly in the system catalogs, despite the fact that end user applications are known to use them via JDBC drivers and libpq, as well as directly. I wonder if we can give this the same kind of compatibility requirements, where it must not break within a given major version but may break between them. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
