Re: libpq URL syntax vs SQLAlchemy

Alex <ash(at)commandprompt(dot)com> writes:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>
>> I have been reviewing how our new libpq URL syntax compares against
>> existing implementations of URL syntaxes in other drivers or
>> higher-level access libraries. In the case of SQLAlchemy, there is an
>> incompatibility regarding how Unix-domain sockets are specified.
>>
>> First, here is the documentation on that:
>> http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html
>>
>> The recommended way to access a server over a Unix-domain socket is to
>> leave off the host, as in:
>>
>> postgresql://user:password@/dbname
>>
>> In libpq, this is parsed as host='/dbname', no database.
>
> Ah, good catch: thanks for heads up.
>
> I believe this was introduced lately in the dev cycle when we've noticed
> that users will have to specify some defaults explicitly to be able to
> override other defaults, while avoiding the whole "?keyword=value&..."
> business.
>
> I'll give this another look and will get back with a proposal to fix
> this in form of a patch.

Upon closer inspection of the issue I came to believe that the proper
fix is to drop support for special treatment of "host part" starting
with slash altogether.

Attached is a patch to do that.

While the following type of URIs is still valid, the interpretation is
now different and is standards-conforming: the part after the
double-slash is treated as "path" specification and not authority
("host".)

postgres:///path-spec

Since the path from a URI translates into dbname connection option, the
only meaningful use of this type of URIs is the following:

postgres:///mydb

The host part in this case is empty (it is "hidden" between the "//" and
the following "/",) thus local socket connection is employed for this
type of URIs. To specify non-standard path to the local sockets
directory use the familiar URI parameter:

postgres:///db?host=/path/to/socket/dir

Also, if my reading of the RFC is correct, the username, password and
port specifiers may be omitted even if the corresponding designators are
present in URI, so we need to remove some checks on empty URI parts.

The test input and expected output files, the docs and code comments are
also updated, of course.

Finally, to complete the RFC compliance, I've added code to properly
handle percent-encoding in query parameter keywords.

At this point, I feel rather silly that we've produced and committed an
"almost" compliant version, which still requires quite a bit of
patching to become an RFC-conforming implementation...

--
Regards,
Alex