Re: Event Triggers: adding information

On 01/18/2013 04:24 AM, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 17 January 2013 16:15, Robert Haas <robertmhaas(at)gmail(dot)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