Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> writes:
>> Installing it per-conn doesn't get you anything. pqtypes has already
>> been linked in. If you use PQexec and PQgetvalue, the pqtypes code
>> pretty much does nothing. So, a per-conn install seems redundant. You
>> are installing the same function pointers under the same name over and
>> over. If you link with, it should just be available.
>
> I don't really agree with that argument; it's not impossible that you'd
> want it on some connections and not others. The server version for
> instance could affect the choice.
>
> Per-conn install also gets you out of a bunch of thread safety issues
> (because we've already decreed that it's the app's problem to ensure
> that only one thread touches a PGconn at a time).
>
> regards, tom lane
>
>
AFAICS, thread-safety is the big problem. I didn't really like the
locking code either -- I was grimacing while typing the code.
Server version is handled by the fact that state is not global, only the
hook callbacks are. If you don't use a pqtypes function, there is no
memory or performance overhead (the real overhead was added at link
time). An application has to toggle based on PQserverVersion, to
install or not install the pqtypes objhooks. Although, more toggling is
needed to choose PQgetvalue over PQgetf for instance.
But, the community has held their ground on using hooks. We tried to
sell our stubs idea but no one was buying. So, per-conn hooks it is.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/