Re: Event Triggers: adding information - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Event Triggers: adding information
Date
Msg-id CA+U5nMLxO9gi862cToRTPGeyASchzi1855=x-NGjBfwZBaKNzw@mail.gmail.com
Whole thread Raw
In response to Re: Event Triggers: adding information  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Event Triggers: adding information
List pgsql-hackers
On 17 January 2013 20:24, Tom Lane <tgl@sss.pgh.pa.us> 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.

So why does focusing on a use case make this turn into an unfixable
morass? The two things are completely unrelated.

If the patch is anywhere close to an unfixable morass, let's just
reject it now. But Robert's arguments were much more tenuous than
that.

My comments were in response to this

> I don't really agree with that.  I think the point is to expose what
> the system is doing to the DBA.  I'm OK with exposing the fact that
> creating a table with a serial column also creates a sequence.  There
> is no problem with that - it's all good.  What we DON'T want to do is
> set up a system where the fact that it creates a sequence is exposed
> because that happens to go through ProcessUtility() and the fact that
> it creates a constraint is not because that happens not to go through
> ProcessUtility().  That is not the sort of quality that our users have
> come to expect from PostgreSQL.

The above functionality is sufficient to allow DDL replication. What
else do we want to do that requires some other capability?

Discussing things in terms of what we will actually use a feature for
is how we know we've got it right. And if it does that, we don't need
anything else.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave
Next
From: Tom Lane
Date:
Subject: Re: Event Triggers: adding information