Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> 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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
