From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: koichi.dbms@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows
Date: Fri, 06 Dec 2024 15:14:37 -0500
Message-ID: <2850994.1733516077@sss.pgh.pa.us> (raw)
In-Reply-To: <2840430.1733510664@sss.pgh.pa.us>
References: <20241206.142130.1661155698933375612.ishii@postgresql.org>
<CABEZHFurokPoY+Vs0zhSf7J5ahZV1p7naOPiH5_3C-ubPdDWgA@mail.gmail.com>
<2751825.1733464455@sss.pgh.pa.us>
<20241206.154248.1191531539866262856.ishii@postgresql.org>
<2840430.1733510664@sss.pgh.pa.us>
I wrote:
> Anyway, what I'm now thinking is that we can have two variants
> of canonicalize_path:
> extern void canonicalize_path(char *path);
> extern void canonicalize_path_enc(char *path, int encoding);
> The first one assumes a server-safe encoding, the second doesn't,
> and at least to start with only psql would bother with the second.
I thought that part would be trivial, but there's a small annoying
problem. The obvious way to write the encoding-aware version of
the de-backslashing loop is to use pg_encoding_mblen_bounded().
However, that function is in src/common/wchar.c while path.c
is in src/port/ --- and I believe we have a rule that libpgport
can't depend on libpgcommon. (The dependencies go the other way,
instead.)
Now it's pretty dubious that path.c is in src/port/ at all, because
it does not meet the expectation that that directory is for
functions that replace missing system-library functionality.
(We've trodden pretty hard on that expectation over the years,
but whatever.) So one reasonable fix could be to move path.c
to src/common, but I'm concerned that that would be unsafe to
back-patch. Also, we'd really want to move the externs for
path.c out of port.h, which would cause additional code churn
for callers.
Another way, given that we only really need this to work for
SJIS, is to hard-wire the logic into path.c --- it's not like
pg_sjis_mblen is either long or likely to change. That's
ugly but would be a lot less invasive and safer to back-patch.
I'm leaning a bit to the second way, mainly because of the
extern-relocation annoyance.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, ishii@postgresql.org, koichi.dbms@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows
In-Reply-To: <2850994.1733516077@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox