2009/4/20 Tom Lane <tgl@sss.pgh.pa.us>:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> I find this all a bit premature, given that you haven't clearly defined what
>> sort of user-visible functionality you hope to end up implementing.
>
> That sums up my reaction too --- this looks like a solution in search of
> a problem. The hook itself might be relatively harmless as long as it's
> not in a performance-critical place, but I think people would tend to
> contort their thinking to match what they can do with the hook rather
> than think about what an ideal solution might be.
see mail to Peter, please
>
> I'm also concerned that a hook like this is not usable unless there are
> clear conventions about how multiple shared libraries should hook into
> it simultaneously. The other hooks we have mostly aren't intended for
> purposes that might need concurrent users of the hook, but it's hard
> to argue that the case won't come up if this hook actually gets used.
>
I though about it. The first rule is probably - handler have to work
as filter, and should be (if is possible) independent on order. It is
very similar to triggers.
regards
Pavel Stehule
> regards, tom lane
>
