Re: Command Triggers

On Fri, Jan 20, 2012 at 9:28 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> 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.

Cool.

>>  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 think the OID is better than the name, but if it's easy to pass the
name and schema, then I'm fine with it. But I do think this is one of
those problems that is complex enough that we should be happy to get
the core infrastructure in in the first commit, even with an extremely
limited amount of functionality, and then build on it.
Enhance-and-extend is so much easier than a monolithic code drop.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company