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

Re: Notes on implementing URI syntax for libpq

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Alexander Shulgin <ash(at)commandprompt(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Notes on implementing URI syntax for libpq
Date: 2011-11-24 13:21:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Excerpts from Alexander Shulgin's message of jue nov 24 05:58:57 -0300 2011:

> Excerpts from Martijn van Oosterhout's message of Thu Nov 24 09:40:42 +0200 2011:

> > 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."
> 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 this is misguided.  We don't need to have a URL that specifies a
Unix socket to work on JDBC, because it's obviously not going to work;
if you just have it "ignore" the &unixsocket bit, then the URI is no
longer the same and you could have it connecting to a completely
different server.

I think we should just propose something that will not work in JDBC.
Surely if the user wants an URL that works both in JDBC and libpq, they
should just not use a Unix-domain-socket specifying URI in the first

What about something like

where the < > are present, i.e. if you want to specify a different
socket directory,


and if you just want to use the default location,


A coworker also suggested using a different designator:


> > 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.

I think the question is allowing the URI to specify a service.

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-11-24 13:22:36
Subject: Re: xpath_table
Previous:From: Heikki LinnakangasDate: 2011-11-24 13:07:51
Subject: Re: pg_upgrade relation OID mismatches

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