Re: parse mistake in ecpg connect string

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: kuroda(dot)hayato(at)fujitsu(dot)com
Cc: wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: parse mistake in ecpg connect string
Date: 2021-02-09 04:58:14
Message-ID: 20210209.135814.1486158425746531393.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 9 Feb 2021 02:12:37 +0000, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)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); }
> > > | ecpg_ident{ $$ = $1; }
> > >;
> > Windows will remains wrong(I'm not sure ecpg on windows can use unix socket connection).
> >
> > And if we add the rules in bison files, both ecpg and ecpglib will both parse the host in different ways.
> > Ecpg parse the host by bison rules, and ecpglib parse the host by splitting the connect string use char '@' or char '='.
> > I think it's not a good action.
> >
> > But If we add some description on docs, these problem can be solved in an easy way.
> > Therefore, I prefer to add some description on docs.
>
> 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 look into it.)

> > I think we can add some description on docs, but I don't have ability to write description in English,
> > Can someone help me write a description?
>
> I'm also not a native English speaker, but I put a draft.
> Please review it and combine them if it's OK.
>
> > 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 smile for the same reason:p

> I have no idea how to fix it now, so I added notice that IPv6 should not be used
> in the host part...

Anyway the host part for the unix: method is just for
spelling. Although I think we can further remove ipv4 address, we
don't even need to bother that. (However, I don't object to add "::1"
either.)

I think replacing "hostname" in the unix: method to "localhost" works.

> dbname[(at)hostname][:port]
> tcp:postgresql://hostname[:port][/dbname][?options]
- unix:postgresql://<italic>hostname</>[:<i>port</>]..
+ unix:postgresql://<nonitalic>localhost</>[:<i>port</>]..

@@ -199,6 +199,13 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
any <replaceable>keyword</replaceable> or <replaceable>value</replaceable>,
though not within or after one. Note that there is no way to
write <literal>&amp;</literal> within a <replaceable>value</replaceable>.
+
+ Also note that if you want to specify the socket directory
+ for Unix-domain communications, an option <replaceable>host=</replaceable>
+ and single-quoted string must be used.
+ The notation rule is almost the same as libpq's one,
+ but the IPv6 address cannot be used here.
+

<replaceable> is not the tag to use for "host". <varname> is that.

If we change the "hostname" for the unix: method to be fixed, no need
to mention IP address. (Even if someone tries using IP addresses
instead of localhost, that case is not our business:p)

How about the attached?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
remove-unix-socket-syntax-in-ecpgconnect_2.diff text/x-patch 3.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-02-09 04:59:40 Re: parse mistake in ecpg connect string
Previous Message tsunakawa.takay@fujitsu.com 2021-02-09 04:35:03 RE: [POC] Fast COPY FROM command for the table with foreign partitions