Re: libpq URL syntax vs SQLAlchemy - Mailing list pgsql-hackers

From Alex
Subject Re: libpq URL syntax vs SQLAlchemy
Date
Msg-id 87mx5azlyr.fsf@commandprompt.com
Whole thread Raw
In response to Re: libpq URL syntax vs SQLAlchemy  (karavelov@mail.bg)
List pgsql-hackers
karavelov@mail.bg writes:

> ----- Цитат от Alex Shulgin (ash@commandprompt.com), на 14.05.2012 в 18:16 -----
>
>> Alex <ash@commandprompt.com> writes:
>>
>>
>> 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
>>
>
> And why are we calling "host" the parameter that specifies the path for socket
> dir - it is not host and could be confused with the  host part of the URI (the
> part between // and /). Why do not call it "path" ? So it will become:
>
> postgres:///db?path=/path/to/socket/dir

We call it that way since we rely on existing libpq code to interpret
the value of every parameter in the URI (well, almost: with notable
exception of translating "ssl=true" for JDBC compatibility.)

I don't think anyone would confuse host part of the URI with URI
parameter "?host=..." if we care to express things clearly in the
documentation (which we do I believe.)

Existing implementations, like that mentioned by Peter in the top
message of this thread (SQLAlchemy or was it psycopg2?) already use this
notation, so I don't think we can or should do anything about this,
i.e. there's little point in renaming to "path" or merely supporting it
as an alternative syntax.

--
Alex



pgsql-hackers by date:

Previous
From: karavelov@mail.bg
Date:
Subject: Re: libpq URL syntax vs SQLAlchemy
Next
From: Fujii Masao
Date:
Subject: Re: WalSndWakeup() and synchronous_commit=off