Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg

From: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
To: "James Oden" <joden(at)lee(dot)k12(dot)nc(dot)us>, <pgsql-interfaces(at)postgreSQL(dot)org>
Subject: Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
Date: 1998-08-11 13:02:52
Message-ID: l03110704b1f5e9485099@[147.233.159.109]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message JohnDz 1998-08-11 13:13:38 Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
Previous Message Goran Thyni 1998-08-11 12:22:43 Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg