parse mistake in ecpg connect string

From: "Wang, Shenhao" <wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com>
To: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: parse mistake in ecpg connect string
Date: 2021-02-04 09:25:00
Message-ID: ae52a416bbbf459c96bab30b3038e06c@G08CNEXMBPEKD06.g08.fujitsu.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, hacker

I found in function ECPGconnect, the connect string in comment is written as:

/*------
* new style:
* <tcp|unix>:postgresql://server[:port|:/unixsocket/path:]
* [/db-name][?options]
*------
*/

But, the parse logical seems wrong, like:

tmp = strrchr(dbname + offset, ':');
tmp2 = strchr(tmp + 1, ':')

the value tmp2 will always be NULL, the unix-socket path will be ignored.

I have fixed this problem, the patch attached.
However, since this usage is not recorded in manual[1](maybe this is why this problem is not found for a long time), so how about delete this source directly instead?
Thoughts?

This patch only fix the problem when using a character variable to store the connect string like:

EXEC SQL BEGIN DECLARE SECTION;
char constr[] = "unix:postgresql://localhost:/tmp/a:?port=5435&dbname=postgres";
EXEC SQL END DECLARE SECTION;

If I write a source like:
EXEC SQL CONNECT TO unix:postgresql://localhost:/tmp/a:/postgres?port=5435
EXEC SQL CONNECT TO unix:postgresql://localhost/postgres?host=/tmp/a&port=5435
The program ecpg will report some error when parse .pgc file

I will try to fix this problem later, but it seems a little difficult to add some lex/bison file rules

[1] https://www.postgresql.org/docs/13/ecpg-connect.html#ECPG-CONNECTING

Best regards
Shenhao Wang

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-02-04 09:32:50 Re: making update/delete of inheritance trees scale better
Previous Message Peter Smith 2021-02-04 08:00:56 Re: pg_replication_origin_drop API potential race condition