Peter Eisentraut writes:
> On mån, 2012-05-14 at 18:16 +0300, Alex Shulgin wrote:
>> 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.
>
>
On mån, 2012-05-14 at 18:16 +0300, Alex Shulgin wrote:
> 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.
Committed.
I also updated the docume
Alex Shulgin writes:
>
> 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.
Well, I understand I might be asking for too much, but did anyone had
karave...@mail.bg writes:
> - Цитат от Alex Shulgin (a...@commandprompt.com), на 14.05.2012 в 18:16
> -
>
>> Alex 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
- Цитат от Alex Shulgin (a...@commandprompt.com), на 14.05.2012 в 18:16
-
> Alex 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
Alex writes:
> Peter Eisentraut 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
On lör, 2012-05-12 at 10:32 +0100, Simon Riggs wrote:
> On 9 May 2012 19:17, Peter Eisentraut wrote:
>
> > 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 SQLAlc
>>Simon Riggs wrote:
>>On 9 May 2012 19:17, Peter Eisentraut wrote:
>>
>>> 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 incompatibi
On 9 May 2012 19:17, Peter Eisentraut wrote:
> 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 so
Peter Eisentraut 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
On Wed, May 9, 2012 at 2:17 PM, Peter Eisentraut wrote:
> postgresql://user:password@/dbname
>
> In libpq, this is parsed as host='/dbname', no database.
That is flat wrong.
> - Requiring percent escapes
And this is, IMHO, the right fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
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
12 matches
Mail list logo
