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

libpq URL syntax vs SQLAlchemy

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: libpq URL syntax vs SQLAlchemy
Date: 2012-05-09 18:17:33
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
I have been reviewing how our new libpq URL syntax compares against
existing implementations of URL syntaxes in other drivers or
higher-level access libraries.  In the case of SQLAlchemy, there is an
incompatibility regarding how Unix-domain sockets are specified.

First, here is the documentation on that:

The recommended way to access a server over a Unix-domain socket is to
leave off the host, as in:


In libpq, this is parsed as host='/dbname', no database.

To specify a socket path in SQLAlchemy, you use:


This also works in libpq (bizarrely, perhaps, considering the previous

This libpq behavior is a problem for several reasons:

- It's incompatible with a popular existing implementation.

- It violates RFC 3986, which doesn't allow slashes in the
  "authority" (host, port, user, password) part.

- As a consequence of this, URLs like this will be parsed differently
  (or will fail to be parsed) by existing URL parsing libraries (tried
  Perl URI and Python urllib, for instance).

- Moreover, if these libraries can't parse the URL, it might mean those
  drivers can't adopt that URL syntax.

- It's internally inconsistent, as shown above.

- In most places in PostgreSQL clients, no host means Unix-domain
  socket, but not here.

- It favors the case of non-default Unix-domain socket plus default
  database over default Unix-domain socket plus non-default database.

- It's not obvious how to get to the default Unix-domain socket at all.
  "postgresql:///dbname" doesn't work, but "postgresql:///dbname?host="

I think this whole approach of using unescaped slashes in the "host"
part of the URL is going to cause lots of problems like this.  We should
consider one or more of:

- Requiring percent escapes

- Requiring specifying the socket path as a parameter, like in the
  above example

- Requiring some delimiters like for IPv6 addresses (which had the
  same problem of reusing a reserved character) (probably a bad idea,
  since we can't make existing URL parsing libraries understand


pgsql-hackers by date

Next:From: Michael NolanDate: 2012-05-09 18:36:57
Subject: Re: problem/bug in drop tablespace?
Previous:From: Peter EisentrautDate: 2012-05-09 17:54:53
Subject: pgsql: Split contrib documentation into extensions and programs

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