Skip site navigation (1) Skip section navigation (2)

Re: Notes on implementing URI syntax for libpq

From: Alexander Shulgin <ash(at)commandprompt(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Notes on implementing URI syntax for libpq
Date: 2011-11-24 08:58:57
Message-ID: 1322123388-sup-3277@moon (view raw or flat)
Thread:
Lists: pgsql-hackers
Excerpts from Martijn van Oosterhout's message of Thu Nov 24 09:40:42 +0200 2011:
> On Thu, Nov 24, 2011 at 08:59:56AM +0200, Alexander Shulgin wrote:
> > > How would you specifiy a local port/UNIX domain socket?
> > 
> > Missed that in my previous reply.
> > 
> > If host part of the URI points to localhost, the UNIX domain socket would be considered by libpq just as if you would pass "-h localhost -p 5433".
> 
> Uh, no it doesn't. "-h localhost" uses TCP/IP (try it). This is one
> piece of mysql magic we don't copy.  If you want to use the socket you
> need to specify "-h /tmp" or wherever you keep it.  Leaving out the -h
> parameter also uses UNIX domain sockets.

Oh, you're right -- I was under wrong impression (hacking in the wrong local install, you know.)

> Which does raise the valid question of how to represent that in URI
> syntax. SQLAlchemy (for example) doesn't try with it's URL syntax, to
> connect to a non-default UNIX socket, you need to create the URL object
> directly.

Well, whatever syntax we're going to invent here: it is not supported by the JDBC driver.

 "Because Java does not support using unix sockets the PostgreSQLâ„¢ server must be configured to allow TCP/IP connections."

  http://jdbc.postgresql.org/documentation/head/prepare.html

Or, this has to be done not in the URI syntax itself, but with the use of some external option.

Or maybe we can just add &unixsocket=... and hope that JDBC simply ignores that?  I think I will try the last option to see if that's the case.  (Looking at libpq code, I think we will also need to verify that host/hostaddr parameter is pointing to the local host and reset it to NULL, to actually make libpq consider UNIX sockets.)

> How about the "service" option, that's a nice way of handling
> non-default socket options.

The service handling isn't going to be affected with the proposed approach.  So, if PGSERVICE is given, the options from the service file are applied after the URI is parsed, filling any parameters not set using previous methods.

--
Alex

In response to

Responses

pgsql-hackers by date

Next:From: Florian WeimerDate: 2011-11-24 09:03:25
Subject: Wire protocol: type-specific opt-in to binary format
Previous:From: Pavel GolubDate: 2011-11-24 08:55:01
Subject: Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group