Hi, Kuroda-san:
Kuroda, Hayato/黒田 隼人 wrote:
> * parse_options() was not refactored because
> it does not affect to parsing the host.
> I will try it if should be.
It seems host only can be the name of server, please refer [1].
And if I use command:
./bin/psql "postgresql://server1:2
Dear Wang,
Thank you for giving comments!
I forgot to write that parse functions imitates libpq's functios,
but you understood that immediately. Genius!
> So, I think parse_options() is not need to be refactored.
OK.
> I think we can use the message as same as the message in fe-connect.c:
> > l
Sorry for sending again.
> * Only an SQL literal or a host variable is acceptable.
> I understand we should support other notations, but now hacking.
I tried to add support notation. Now unquoted string can be used.
In the flex file, IPv6 string is parsed with the square bracket, it means
the f
Dear Hackers,
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
co
On Fri, Mar 05, 2021 at 01:56:38AM +, kuroda.hay...@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
>
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 st
On Mon, Jun 21, 2021 at 3:46 AM kuroda.hay...@fujitsu.com <
kuroda.hay...@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.
