From: Craig Ringer <craig@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Alvaro Herrera <alvherre@2ndQuadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Event Triggers: adding information
Date: Fri, 18 Jan 2013 10:27:36 +0800
Message-ID: <50F8B318.1060407@2ndQuadrant.com> (raw)
In-Reply-To: <16675.1358454278@sss.pgh.pa.us>
References: <m2txrsdzxa.fsf@2ndQuadrant.fr>
<m2zk1j9c44.fsf@2ndQuadrant.fr>
<CA+Tgmob6kmAySE5yXvd3uE9LifHunufMg9iU3GmbJ5bpGPiHjQ@mail.gmail.com>
<m2k3sbe51z.fsf@2ndQuadrant.fr>
<CA+TgmoZjOACnHOKrz-eucj3FJXrYJzA-_yjSqajOQR8qkjCi=w@mail.gmail.com>
<m2bodi55yn.fsf@2ndQuadrant.fr>
<CA+TgmoZTxXGAkoyQD0aNOyju1X19SnVfk7KV9fsJCv63bS-C4g@mail.gmail.com>
<m27go1ot1a.fsf@2ndQuadrant.fr>
<20130104205251.GB9191@alvh.no-ip.org>
<m28v88pqin.fsf@2ndQuadrant.fr>
<20130109165829.GB4490@alvh.no-ip.org>
<CA+TgmobykpymdGyfbCDEfS6+-50X-AKYTdK88fjMS4-mY5SBdw@mail.gmail.com>
<m2ehhkrfqk.fsf@2ndQuadrant.fr>
<CA+TgmobfeB_YpgMv5NjW52tG36Hg_DY=jq0XDkE5zwCstPQ4pg@mail.gmail.com>
<m2pq14m7sx.fsf@2ndQuadrant.fr>
<CA+TgmoYEW583z+oisToCYQMz2grzpavdXrCi3-W2D_+nucVhzQ@mail.gmail.com>
<CA+U5nM+Uuh7cyHSJ5wN54twBUGSncJzqpZB83xuZw4VP7UCziQ@mail.gmail.com>
<16675.1358454278@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 01/18/2013 04:24 AM, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 17 January 2013 16:15, Robert Haas <robertmhaas@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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: craig@2ndQuadrant.com, tgl@sss.pgh.pa.us, simon@2ndQuadrant.com, robertmhaas@gmail.com, dimitri@2ndquadrant.fr, alvherre@2ndQuadrant.com
Subject: Re: Event Triggers: adding information
In-Reply-To: <50F8B318.1060407@2ndQuadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox