Thread: Re: Refactor ECPGconnect and allow IPv6 connection

Re: Refactor ECPGconnect and allow IPv6 connection

From
Michael Paquier
Date:
On Fri, Mar 05, 2021 at 01:56:38AM +0000, kuroda.hayato@fujitsu.com wrote:
> I reviewed for myself and fixed something:
>
> * refactor parse_options(), same as conninfo_uri_parse_params() in libpq
>   Skipping blanks is needed in this functions because ecpg precompiler add additional blanks
>   between option parameters. I did not fix precompiler because of the compatibility.
>   If it changes, maybe SO_MAJOR_VERSION will be also changed.
> * update doc

As you are writing in your first bullet point and as mentioned
upthread, it does not strike me as a great idea to have a duplicate
logic doing the parsing of URIs, even if libpq accepts multiple
hosts/ports as an option.  Couldn't we have a better consolidation
here?
--
Michael

Attachment

RE: Refactor ECPGconnect and allow IPv6 connection

From
"kuroda.hayato@fujitsu.com"
Date:
Dear Michael,

Thank you for replying!

> it does not strike me as a great idea to have a duplicate
> logic doing the parsing of URIs, even if libpq accepts multiple
> hosts/ports as an option.

Yeah, I agree your argument that duplicated parse function should be removed.

ECPG parses connection string because it uses PQconnectdbParams()
even if target is specified in the new-style,
hence my elementary idea is that the paring can be skipped if PQconnectdb() calls.

I will try to remake patches based on the idea.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED




Re: Refactor ECPGconnect and allow IPv6 connection

From
"David G. Johnston"
Date:
On Mon, Jun 21, 2021 at 3:46 AM kuroda.hayato@fujitsu.com <kuroda.hayato@fujitsu.com> wrote:
I will try to remake patches based on the idea.

Based upon this comment, and the ongoing discussion about commitfest volume and complexity, I've moved this to "Waiting on Author".

David J.