From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch for 8.5, transformationHook |
Date: | 2009-04-20 16:56:47 |
Message-ID: | 162867790904200956x735f94e9rf7cb24e4ab61e4df@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/4/20 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Peter Eisentraut <peter_e(at)gmx(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Eric B. Ridge | 2009-04-20 18:27:44 | 8.4b1 regression? |
Previous Message | Pavel Stehule | 2009-04-20 16:53:14 | Re: Patch for 8.5, transformationHook |