Simon Riggs <simon@2ndquadrant.com> writes:
> On 17 January 2013 20:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
I think you and Robert are talking past each other. Whether it is or
is not sufficient for DDL replication is not what he is concerned about;
what he's worried about is whether we can refactor the backend in future
without causing a user-visible change in the events that event triggers
see. I think that that is an entirely valid concern, and it's not going
to go away on the strength of "but this is enough to let us do
replication".
The other point I'd make here is what I just said to Dimitri: it's far
from proven, AFAIK, that this actually *is* sufficient to allow DDL
replication. I'd be a lot happier if we had a working proof of that
before we lock down a SQL-level facility that we're going to have a hard
time changing the details of. Maybe we should just introduce some
C-level hooks and let you guys go off and code replication using the
hooks, before we put in a lot of expensive infrastructure that might
turn out to be Not Quite The Right Thing. After we *know* the hooks
are in the right places and supply the right information, we can look at
replacing them with some more formalized facility.
regards, tom lane