Обсуждение: Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg

>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

At 13:57 +0300 on 11/8/98, James Oden wrote:


> 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

There is no port of libpq for the Mac. It is much more complicated than you
think. First, Mac programmers don't use malloc. The MacOS has its own
memory manager and you use "handles" (system-created double pointers).
Then, shared libraries depend (if I'm not mistaken) on the code-fragment
manager, which exists on PPC machines, and has many problems on 68k
machines. In short, nobody has done it so far, and it is far from being a
"change all socket calls to their mac equivalent and say AbraKadabra".

Now imagine one of the less commonly used systems - like, say, BeOS. You
have to have a BeOS maven to port libpq there.

Hey, but that's exactly why cross-platform languages have been invented.
The principle is quite simple: An OS guru ports the language ONCE, and
then, anybody who knows the language (and many, many people know perl, TCL
etc), can write the Postgres port to that language.

I mean, what are the chances of finding someone who both understands the
Postgres protocol *and* the MacOS? But a perl port for the MacOS already
exists. So, what are the chances of finding someone who knows both the
Postgres protocol and perl? Much higher, wouldn't you say?

It wouldn't save too much time in updating the source tree, either. A
change of protocol would require updating all the available ports of libpq,
instead of the available ports for the existing languages. I don't see much
improvement here. Moreover, a situation like the ODBC port could arise
again - the old maintainer is no longer available, and a new one is
required to step in. The odds of finding a MacOS/BeOS/whatever guru *twice*
are pretty close to zilch. But a maintainer for the common languages can be
found much more easily - if only because each of the various languages have
a much wider audience than the esoteric OS's.

POSIX, I'm sorry to say, is totally useless.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma