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

On 13/09/2003 00:53 Tom Lane wrote:
> Paul Thomas <paul@tmsl.demon.co.uk> writes:
> > On 12/09/2003 20:20 Deepak Bhole wrote:
> >> We are trying to add support for Unix sockets to the current jdbc
> >> (for
> >> our own release for now). The support is added via gnu
> classpath,located
> >> at: http://www.nfrese.net/software/gnu_net_local/overview.html
>
> > Why on earth are you trying to pollute the JDBC driver with
> > platform-specific non-portable features that can be of no possible
> benefit
> > to anyone except commercial companies attempting to use any underhanded
>
> > means to lock customers into their product? Are you trying be the new
> > Microsoft?
>
> You got up on the wrong side of the bed today?  What's platform-specific
> about Unix sockets?

Well, Sun must regard them as pretty platform-specific as they're not part
of the Java spec. In practice there's another issue. Its called binary
compability. PostgreSQL users currently have the luxury of a type-4 (i.e.,
pure Java) JDBC driver. So a driver can be built on a Linux box (for
example) and that binary will also run on Windows, Solaris... Unix sockets
would have to be accessed though JNI thus making the driver a type-3
driver. Kiss goodbye to binary portability. And forget running the driver
on Windows without (I would imagine) cygwin installed - and that would
re-map to tcp/ip sockets "pretending" to be unix sockets - can't see much
advantage in that one. Forget using JDBC from applets to as that requires
a type-4 driver. Not that I would imagine that there are many people doing
JDBC from applets but the ability is there ATM. That kind of portability I
live without!

It really alarms me to think that the type-4 driver might get "demoted" to
type-3:

"(for our own release for now)"
                        ~~~~~~~

I've had some really bad experiece of type-3 drivers over last couple of
years, especially regarding VM crashes :(. I'm sure a lot of this is
because JNI can be a real b*****d to debug rather that any reflection on
the programmers. Not that that's of any comfort to the users of a web
application which crashes twice a day.

> > Get real. If Red Hat want to improve the JDBC driver, the ability to
> > properly use server side prepared statements from a JDBC connection
> pool
> > would give a massively bigger performance gain that anything you
> possibly
> > ever get between tcp/ip and unix sockets.
>
> Deepak did not state or imply that the motivation for this was
> performance.
> Actually, it's security: lots of people prefer to run their PG servers
> with no open TCP ports at all.  So it would be good if JDBC could talk
> to such a server.

You can hide the port from the outside world with a firewall and configure
PostgreSQL to only accept tcp/ip connections for 127.0.0.1. And if packet
sniffing on the loopback interface is a concern, is SSL not secure enough?
Having said that, I'm not sure if the JDBC driver supports SSL ATM but
even without it the security argument (as opposed to a dogmatic policy
stance) looks very weak to me which is why I initially discounted it.

> > Can you see why I'm so suspicious about the companies motives?
>
> I'm suspicious about *you*.  Who are you to tell other people how to
> spend their time?  And in such an impolite fashion?

I haven't told anybody to do anything and any issues regarding politeness
or otherwise are entirely your own interpretation.

>
> > And just for the record, I'm 100% Red Hat Linux user.
>
> Just for the record, I work for Red Hat.

I'm aware of that. But you need to be aware that:

a) the view of your company you get from the inside may be somewhat
different from the view that outsiders get

b) not everyone on the planet automatically assumes that the management of
your, or any other, company are saints driven by purely altruistic intent.
History shows that the opposite is overwhealming the case. Customers
wouldn't be offering your company money for a type-3 driver by any chance
would they?

c) one of the main reasons that people choose to program in Java is
because of its cross-platform binary abilities. Proposing changes which
undermine that ability are unlikely to win you (the company) many friends

d) there are some of us who through commercial experience don't want
either the potential instability or installation PITA of a type-3 driver.
ATM I can deploy PostgreSQL and the JDBC driver to my clients in the
knowledge that both have rock-solid stability. Do you think I would want
risk that?

So let's look at what the future may hold. I would guess that you're
already been told to to produce a type-3 driver for whoever. That's not an
issue for me. Where I start to worry is if you then decide to donate the
changed driver to the main source tree. Can the changes be merged in so
that a type-4 driver can still be built? Who knows? Are you going to
guarantee the continued existence and development of the type-4 driver or
will we all be forced to either use the type-3 or hack up our own type-4
drivers? And what about testing? Bugs in a type-3 driver can crash the JVM
so a very high level of stress testing will be required, probably on
multiple platforms. Are Red Hat going to make resources available for the
required level of testing? For years to come?



--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants         |
http://www.thomas-micro-systems-ltd.co.uk   |
+------------------------------+---------------------------------------------+