Hi, hacker
I found in function ECPGconnect, the connect string in comment is written as:
/*--
* new style:
* :postgresql://server[:port|:/unixsocket/path:]
* [/db-name][?options]
*--
*/
But, the parse logical seems wrong, like:
tmp = strrchr(dbname + offset, ':');
tmp2 = s
At Thu, 11 Feb 2021 15:23:31 -0500, Tom Lane wrote in
> "kuroda.hay...@fujitsu.com" writes:
> > Dear Wang, Horiguchi-san,
> >>> How about the attached?
>
> >> I think, this patch is good.
>
> > I agree. The backward compatibility is violated in the doc, but maybe no
> > one take care.
>
> Pu
At Thu, 4 Feb 2021 09:25:00 +, "Wang, Shenhao"
wrote in
> Hi, hacker
>
> I found in function ECPGconnect, the connect string in comment is written as:
>
> /*--
> * new style:
> *:postgresql://server[:port|:/unixsocket/path:]
> *[/db-name][?options]
> *--
> */
>
> But,
Dear Wang,
> the value tmp2 will always be NULL, the unix-socket path will be ignored.
I confirmed it, you're right.
> I have fixed this problem, the patch attached.
It looks good to me:-).
> I will try to fix this problem later, but it seems a little difficult to add
> some lex/bison file ru
Dear Horiguchi-san,
My response crossed in the e-mail with yours. Sorry.
> FWIW, directly embedding /unixsocket/path syntax in a URL is broken in
> the view of URI. It is the reason why the current connection URI takes
> the way shown above. So I think we want to remove that code rather
> than to
Hi, Horiguchi-san, Kuroda-san:
Thank you for reviewing.
Kyotaro Horiguchi wrote:
>FWIW, directly embedding /unixsocket/path syntax in a URL is broken in
>the view of URI. It is the reason why the current connection URI takes
>the way shown above. So I think we want to remove that code rather
>t
"Wang, Shenhao" writes:
> Kyotaro Horiguchi wrote:
>> FWIW, directly embedding /unixsocket/path syntax in a URL is broken in
>> the view of URI. It is the reason why the current connection URI takes
>> the way shown above. So I think we want to remove that code rather
>> than to fix it.
> It see
Dear Wang, Tom
> I think add the bison rule is a little difficult because in PG13 windows can
> also support unix-socket,
> In your patch:
> > dir_name: '/' dir_name{ $$ = make2_str(mm_strdup("/"), $2); }
> > | ecpg_ident{ $$ = $1; }
> >;
> Windows will remains wrong(I'm not sure ecpg on windows
At Tue, 9 Feb 2021 02:12:37 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Wang, Tom
>
> > I think add the bison rule is a little difficult because in PG13 windows
> > can also support unix-socket,
> > In your patch:
> > > dir_name: '/' dir_name{ $$ = make2_str(mm_strdup("/"), $2); }
> >
At Tue, 09 Feb 2021 13:58:14 +0900 (JST), Kyotaro Horiguchi
wrote in
> > I didn't care about the windows environment.
> > Somewhat WIN32 directive can be used for switching code, but I agree your
> > claims.
>
> This thread looks like discussing about unix-domain socket on
> Windows. (I'll loo
Hi, Horiguchi-san
Kyotaro Horiguchi wrote:
> How about the attached?
I think, this patch is good.
> > > Should we allow "::1" here as well? On the other hand, colons are
> > > already overloaded in this syntax, so maybe allowing them in the
> > > host part is a bad idea.
> Yeah, that made me
Dear Wang, Horiguchi-san,
> > How about the attached?
>
> I think, this patch is good.
I agree. The backward compatibility is violated in the doc, but maybe no one
take care.
> Maybe we can create a new thread to talk about how ecpg support ipv6
+1
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
"kuroda.hay...@fujitsu.com" writes:
> Dear Wang, Horiguchi-san,
>>> How about the attached?
>> I think, this patch is good.
> I agree. The backward compatibility is violated in the doc, but maybe no one
> take care.
Pushed with a little more work on the documentation.
13 matches
Mail list logo
