>At 19:44 +0300 on 10/8/98, Edmund Mergl wrote:
>
>
>> I suggest to spend the effort on making libpq thread safe.
>> Otherwise we end up with two DBD modules for postgres.
>> If you prepare a module, which does not depend on libpq,
>> you will have much more effort on keeping it up to date.
>> The main goal of an interface like libpq is to avoid such
>> dependencies.
>
>On the other hand, making a DBD module which is not dependent on libpq will
>make it possible to use the perl interface on platforms other than UNIX
>(e.g. Win, Mac).
Actually, that is not completely the case. libpq itself has been ported to
a Win32 environment as far as I know, and besides that there is no reason
that it couldn't be, and thus make the Perl DBD module portable. For
porting purposes on Win 95/NT there is Cygnus's GNU/Win 32 stuff which seems
to work pretty well, even in the area of sockets (*yes you can even do
sockets on a Win 95 machine without having to know the WinSock API).
On Macintosh, I'm not sure. I can't think of any reason why libpq could be
ported to the Mac environment. Its only a C interface, though, probably a
lot of code would have to be changed to support Mac's network api (I feel
real unsure here. I have never written any code for a Mac, except in
WordBasic [there's a language I don't put on my résumé]). Also, the GNU
compilers have been ported to the Mac (though, I am unsure of their
usefullness there yet) so that's another possibility in helping to port
libpq.
Anyway, the point I am making is that probably it would be better to have
one API that all of your code is dependent upon under the hood to talk to
the PostgreSQL backend. If libpq isn't ready for that, it probably ought to
be made that way. Otherwise the developers will end up with a lot of
completely independent source trees to maintain, which translates into a
support nightmare...james
>
>So, if potential users have any say on the matter, I'd ask that interfaces
>for various cross-platform languages be kept as platform-independent (that
>is, as free of native code) as possible.
In that case you want them to stay as close to POSIX in the libpq code as
possible, and leverage the POSIX subsystems on most OS's today (OS/400 for
the AS/400 even has a POSIX subsystem, and so does Open VMS). I havn't
looked closely at the code for libpq, but I have assumed up to know that
probably the developers of it stuck as best they could to POSIX just because
this product tends to get ported everywhere.
Shalom...james