2009/4/20 Tom Lane <t...@sss.pgh.pa.us>: > Peter Eisentraut <pete...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
