Re: Last gasp - Mailing list pgsql-hackers

On Fri, 2012-04-06 at 00:02 +0200, Dimitri Fontaine wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Huh?  AFAICS, there are vestiges of the old terminology all over the
> > patch, although some very incomplete renaming has been done.  I'm
> > pretty sure you haven't made the firing points consistent either,
> > although I'd have to spend more time reviewing to be sure of that.
> 
> I've choosen to internally have command triggers built in an event
> trigger framework, because clearly the only kind of events we have an
> idea how to manage are commands here. Don't generalize an API with only
> one use case, etc. So internally it's very much command oriented, while
> the usage is all about "events".
> 
> The firing point didn't move yet, I finished the mechanism. It's now
> about picking the right event name for each of them, I've begin to
> explore about that in aggregatecmds.c already. So I think that's only a
> policy issue now when it was just impossible some days ago.
> 
> > I think it's fair to say that there's probably another month of work
> > here to get this committed.  It is, of course, up to the community as
> > a whole whether they want to delay 9.2 another month for this and
> > perhaps other patches that are not yet done.  But the idea that we're
> > going to pull it together into committable form in the next 24 hours
> > is not realistic.
> 
> All of that depends on what you want to see commit, I'm still under the
> illusion that parts of it are going to be salvaged. 

I would really like the controversial parts of the recent feature creep
to get un-creeped :)

At least until 9.3 .

> For example we could
> decide to implement "command_start" and "commend_end" in utility.c and
> remove all special variables support apart from the parse tree for user
> functions written in C. That would already be something.

I would need only one of those - just something to record the DDL
command that was done. 

I'd prefer to get "command_end" triggers if "command_start" would mean
it could fail later.

CREATE TRIGGER AFTER ANY DDL EXECUTE record_ddl();

My next wish after the above is available would be triggers on
BEGIN/ROLLBACK/COMMIT to implement "streaming" and possibly also
"synchronous" logical replication - the current logical replication
systems rely on trigger-gathered events only being available after
commit and so don't need to get notified about COMMIT/ROLLBACK.

CREATE TRIGGER AFTER BEGIN EXECUTE remote_transaction_begin_();
CREATE TRIGGER AFTER ROLLBACK EXECUTE remote_transaction_rollback();
CREATE TRIGGER AFTER COMMIT EXECUTE remote_transaction_commit();

> Of course as I wasn't running for that outcome that's not what you
> currently see in the branch.

I would very much like to see the stripped down, after command only
version to get into 9.2

I would not mind at all waiting a week or two for this to happen.

And i promise I will keep a very keen eye on further development and
also will start testing right away for it being sufficient for DDL
replication as soon as the stripping is completed :)

Also, I suspect that the rest of the "event" trigger functionality could
better be served as simple hooks anyway, at least until we have some
good real life use-case to test against before working on a more
involved implementation.

> Regards,
> -- 
> Dimitri Fontaine
> http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support
>