Craig James wrote:
> Don't confuse thread-friendly with a threaded implemetation of
> Postgres itself. These are two separate questions. Thread-friendly
> involves compile/link options that don't affect the Postgres source
> code at all.
Indeed. I'm specifically not suggesting that Postgres should offer an
API that can be called from
anything except the initial thread of its process - just that library
subsystems might want to use
threads internally and that should be OK. Or rather, it should be
possible to build Postgres
so that its OK. Even if there's a small slowdown, the benefit of
running the full JVM or CLR
might outweigh that quite easily *in some circumstances*.
I've also hinted that at some stage you might want to thread some parts
of the implementation,
but I'm not suggesting that would be an early target. It seems to me
sensible to make it
straightforward to take baby steps in that direction in future would be
a reasonable thing to
do. As would being friendly to dynamically loaded C++ code. If you
create the framework,
(and we're talking the barest of scaffolding) then others can work to
show the cost/benefit.
I fail to see why this would be a controversial engineering approach.
James