RE: parse mistake in ecpg connect string

From: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com" <wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: parse mistake in ecpg connect string
Date: 2021-02-08 03:02:26
Message-ID: OSBPR01MB31573F75BE36C7EF89348AF8F58F9@OSBPR01MB3157.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 rules

I think rule `connection_target` must be fixed.
Either port or unix_socket_directory can be accepted now(I followed the comment),
but we should discuss about it.
According to the doc, libpq's connection-URI accept both.

The attached patch contains all fixes, and pass test in my environment.
And the following line:

EXEC SQL CONNECT TO unix:postgresql://localhost:/a:/postgres;

is precompiled to:

{ ECPGconnect(__LINE__, 0, "unix:postgresql://localhost:/a:/postgres" , NULL, NULL , NULL, 0); }

Is it OK?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

Attachment Content-Type Size
v2-0001-fix-strchr-strrchr-mistake.patch application/octet-stream 3.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.hayato@fujitsu.com 2021-02-08 03:25:58 RE: parse mistake in ecpg connect string
Previous Message Kyotaro Horiguchi 2021-02-08 03:00:20 Re: parse mistake in ecpg connect string