Re: Specification of "/" in the host name (for Unix socket support) - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: Specification of "/" in the host name (for Unix socket support)
Date
Msg-id 20030917222645.GA29421@opencloud.com
Whole thread Raw
In response to Re: Specification of "/" in the host name (for Unix socket support)  (Paul Thomas <paul@tmsl.demon.co.uk>)
Responses Re: Specification of "/" in the host name (for Unix socket support)  (Paul Thomas <paul@tmsl.demon.co.uk>)
List pgsql-jdbc
On Wed, Sep 17, 2003 at 03:14:10PM +0100, Paul Thomas wrote:

> Firewall + ACL <> single layer! I suppose the rest of it depends on
> whether or not you're pitching a system to be idiot-proof. Personally, I
> don't regard Unix Sysadmin as the ideal career for an idiot and I have
> little (make that zero) sympathy for companies that do ;)

Well, I can see I'm not convincing you of the benefits of "do it the
simplest possible way", and I'm no security evangelist. But can you accept
that others might find disabling the TCP/IP listener useful, even if you
don't?

> >> Well, if all of this is a must-have then Java is probably the wrong
> >> language to use.
> >
> >Why, exactly? It sounds all do-able (and not too painful, either) to me.
>
> I don't subscribe to the view that just because something is do-able means
> that doing it is necessarily a wise thing. That way lies the madness of
> feature-bloat. Who is going to maintain the JNI code? ATM, the JDBC driver
> only requires Java knowledge. Add JNI and a whole new skill set is
> required. All-in-all, I think the long-term pain could be a lot worse that
> you currently believe.

So you are saying: we should not support unix domain sockets because
the standard Java libraries do not provide an interface to them, and
maintaining a custom interface is expensive.

There are enough interested people out there that I don't think maintenance
will be any more of an issue than it is with the rest of the driver. The JNI
code that's needed would be isolated, not very complex, and probably
maintained as part of a third-party library anyway.

I don't think this is feature bloat at all, it's supporting an existing,
useful, feature of the backend. It's not "pgsql over avian carriers".

-O

pgsql-jdbc by date:

Previous
From: Ron
Date:
Subject: Re: Batch Processing - Autocommit
Next
From: Barry Lind
Date:
Subject: Re: Batch Processing - Autocommit