Re: enabling tcpip_socket by default

From: Doug McNaught <doug(at)mcnaught(dot)org>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: enabling tcpip_socket by default
Date: 2004-05-17 22:01:34
Message-ID: 873c5yiugx.fsf@asmodeus.mcnaught.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:

> Doug McNaught <doug(at)mcnaught(dot)org> writes:
>
>> Java doesn't support Unix domain sockets. If you want to use JDBC,
>> you have to use TCP sockets.
>
> That doesn't follow. That just means you can't implement a unix domain socket
> driver using only Java. Is there some reason the driver has to be pure a Java
> driver?

Well, no. But then you get into the horror that is JNI, and the need
to maintain that glue layer (there's a substantial impedance mismatch
between libpq and the JDBC API) on all platforms.

> I had always assumed the JDBC driver isn't currently pure java and is just an
> API wrapper around libpq. Writing and maintaining a pure java driver would be
> much more work and be much slower for no practical gain.

The JDBC driver is and always has been pure Java, and I'm damn glad.
If your app is all Java, all you have to do is add the driver jar to
the classpath and you're done--no libpq, no .so version mismatches,
etc. AFAIK (I'm not one of the developers) there are no plans to
write a JNI layer just for Unix sockets.

And I doubt very much that it's that much slower in most cases,
especially with modern JIT compilers. You'll take a bit of a hit from
the TCP overhead, but in practice for most apps it won't be an issue.

-Doug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-05-17 22:48:31 Re: Call for 7.5 feature completion
Previous Message Andrew Dunstan 2004-05-17 22:00:48 Re: enabling tcpip_socket by default