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

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 (view raw, whole thread or download thread mbox)
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!


In response to

pgsql-hackers by date

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

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