Greg Smith <greg(at)2ndQuadrant(dot)com> writes:
Thank you for the review, Greg!
> Given that, there really isn't a useful path forward that helps out
> all those developers without supporting both prefixes. That's where
> this left off before, I just wanted to emphasize how clear that need
> seems now.
OK, I've used the code from your earlier review to support the short
prefix. I sincerely hope we don't make the situation any worse by being
flexible about the prefix...
> Next thing, also mentioned at that Flask page. SQLite has
> standardized the idea that sqlite:////absolute/path/to/foo.db is a URI
> pointing to a file. Given that, I wonder if Alex's syntax for
> specifying a socket file name might adopt that syntax, rather than
> requiring the hex encoding: postgresql://%2Fvar%2Fpgsql%2Ftmp/mydb
> It's not a big deal, but it would smooth another rough edge toward
> making the Postgres URI implementation look as close as possible to
Yeah, this is really appealing, however how do you tell if the part
after the last slash is a socket directory name or a dbname? E.g:
psql postgres:///path/to/different/socket/dir (default dbname)
psql postgres:///path/to/different/socket/dir/other (dbname=other ?)
If we treat the whole URI string as the path to the socket dir (which I
find the most intuitive way to do it,) the only way to specify a
non-default dbname is to use query parameter:
or pass another -d flag to psql *after* the URI:
psql [-d] postgres:///path/to/different/socket/dir -d other
> So far I've found only one syntax that I expected this to handle that
> it rejects:
> psql -d postgresql://gsmith(at)localhost
> It's picky about needing that third slash, but that shouldn't be hard
> to fix.
Yeah, good that you've spotted it. If my reading of the URI RFC (2396)
is correct, the question mark and query parameters may follow the
hostname, w/o that slash too, like this:
psql -d postgresql://localhost?user=gsmith
So this made me relax some checks and rewrite the code a bit.
> I started collecting up all the variants that do work as an initial
> shell script regression test, so that changes don't break something
> that already works. Here are all the variations that already work,
> setup so that a series of "1" outputs is passing:
Yes, the original code was just a bit too picky about URI component
separators. Attached also is a simplified test shell script.
I have also added a warning message for when a query parameter is not
recognized and being ignored. Not sure if plain fprintf to stderr is
accepted practice for libpq, please correct if you have better idea.
In response to
pgsql-hackers by date
|Next:||From: Florian Weimer||Date: 2012-02-24 13:07:21|
|Subject: Re: WIP: URI connection string support for libpq|
|Previous:||From: Yeb Havinga||Date: 2012-02-24 12:50:01|
|Subject: Re: [v9.2] Add GUC sepgsql.client_label|