Re: Notes on implementing URI syntax for libpq

From: Alexander Shulgin <ash(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alexey Klyukin <alexk(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Notes on implementing URI syntax for libpq
Date: 2011-11-24 15:22:06
Message-ID: 1322147288-sup-9036@moon
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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:
>
> 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 host to be empty string, the above works like a charm!

--
Alex

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-11-24 15:26:41 Re: pg_upgrade relation OID mismatches
Previous Message Heikki Linnakangas 2011-11-24 15:15:49 Re: PL/Python SQL error code pass-through