From: | Alex Shulgin <ash(at)commandprompt(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: URI connection string support for libpq |
Date: | 2012-02-24 13:01:12 |
Message-ID: | 8762ewz8pz.fsf@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> others.
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:
psql postgres:///path/to/different/socket/dir?dbname=other
or pass another -d flag to psql *after* the URI:
psql [-d] postgres:///path/to/different/socket/dir -d other
Reasonable?
> 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:
>
[snip]
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.
--
Regards,
Alex
Attachment | Content-Type | Size |
---|---|---|
libpq-uri-v4.patch | text/x-diff | 18.3 KB |
psql-uri-regress.sh | text/x-sh | 879 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2012-02-24 13:07:21 | Re: WIP: URI connection string support for libpq |
Previous Message | Yeb Havinga | 2012-02-24 12:50:01 | Re: [v9.2] Add GUC sepgsql.client_label |