Re: Command Triggers

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <greg(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Command Triggers
Date: 2012-01-20 14:28:40
Message-ID: m2ipk6cusn.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> My advice is to forget about trying to provide the command string to
> the user for the first version of this patch. As you're finding out,
> there's no simple, easy, obvious way of doing it, and there are N>0
> useful things that can be done without that functionality.

Actually, none of my current examples and tests are relying on it. For
the trigger based replications Jan said he would need the full parse
tree rather than just the command string anyway, so we're not loosing
anything more that we already were ready to postpone.

> I continue
> to think that for a first version of this, we should be satisfied to
> pass just the OID. I know that's not really what you want, but
> there's much to be said for picking a goal that is achievable in the
> limited time available, and I fear that setting your sights too high
> will lead to something that either (a) doesn't get committed, or (b)
> gets committed, but turns out not to work very well, either of which
> would be less than ideal.

Agreed, mostly.

From the code I already have I think we should still pass in the command
tag, the schema name (or null) and the object name (or null) as input
parameters to the trigger's procedure.

I'm now working on that and then the concurrency angle of the command
triggers.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2012-01-20 14:29:28 Re: our buffer replacement strategy is kind of lame
Previous Message Robert Haas 2012-01-20 14:19:51 Re: JSON for PG 9.2