Excerpts from Robert Haas's message of Thu Nov 24 17:02:13 +0200 2011:
>
> On Thu, Nov 24, 2011 at 9:40 AM, Alexander Shulgin
> <ash@commandprompt.com> wrote:
> >> Another idea is to use local:/dir/name for UNIX domain socket instead of hostname:port, like it's displayed in the
psqlprompt.
> >
> > So the whole thing would look like this:
> >
> > postgresql://local:/dir/name/dbname?param1=val1&...
> >
> > Where "/dir/name" is the absolute path to the directory containing the socket file. If one wants to use the
defaultdirectory the following syntax may serve the need:
> >
> > postgresql://local:/dbname
>
> I think this is just weird. libpq treats any hostname that starts
> with a slash as hostname. And there's a standard way of URL-encoding
> characters that would otherwise be treated as terminators: you write a
> percent sign followed by two hex digits. So if you want the host to
> be /tmp, you just should just write:
>
> postgresql://%2Ftmp/fred
>
> Which is the equivalent of the connection string:
>
> host=/tmp dbname=fred
Yeah, that should work, but it's giving the pathname a really weird look. Given that this is going to be used only
rarely,this is less of a problem, though.
> This may appear to be slightly inconvenient notation, but there is
> little reason to reinvent syntax that the URL gods have already
> devised, and in practice specifying an explicit pathname in a
> connection string is quite rare. One normally specifies a local
> socket connection by omitting to specify a hostname at all, and that
> can work here, too. That is, postgresql:///fred should be equivalent
> to the connection string:
>
> dbname=fred
>
> ...which means it will use the default socket directory on UNIX, and a
> loopback connection on Windows. And postgresql:/// should be
> equivalent to an empty connection string, defaulting everything.
Hm... that's neat. Didn't appear to me due to a bit too restrictive parser rules in my draft patch. Now that I allow
hostto be empty string, the above works like a charm!
--
Alex