Re: Command Triggers

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Command Triggers
Дата
Msg-id m2ipk6cusn.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Command Triggers  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Command Triggers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: JSON for PG 9.2
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: our buffer replacement strategy is kind of lame