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.
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
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2012-01-20 14:29:28|
|Subject: Re: our buffer replacement strategy is kind of lame|
|Previous:||From: Robert Haas||Date: 2012-01-20 14:19:51|
|Subject: Re: JSON for PG 9.2|