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(at)commandprompt(dot)com> wrote:
> >> Another idea is to use local:/dir/name for UNIX domain socket instead of hostname:port, like it's displayed in the psql prompt.
> > 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 default directory 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:
> 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:
> ...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 host to be empty string, the above works like a charm!
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2011-11-24 15:26:41|
|Subject: Re: pg_upgrade relation OID mismatches|
|Previous:||From: Heikki Linnakangas||Date: 2011-11-24 15:15:49|
|Subject: Re: PL/Python SQL error code pass-through|