| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Koichi Suzuki <koichi(dot)dbms(at)gmail(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
| Date: | 2024-12-06 05:54:15 |
| Message-ID: | 2751825.1733464455@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Koichi Suzuki <koichi(dot)dbms(at)gmail(dot)com> writes:
> I'm not sure if we can fix src/fe_utils/psqlscan.l and/or
> src/bin/psql/psqlscanslash.l for this. Needs some more investigqation.
I don't believe the theory that the fault lies there. If the flex
rules were taking the backslash-embedded-in-a-shift-JIS-character
as a backslash, they would think it is the start of a new backslash
command, with the result being that the filename argument gets
truncated there. That doesn't match the reported symptoms: we
see more of the filename than that echoed back in the error message.
So I think the filename is getting through that part just fine,
and then we're messing it up in canonicalize_path or adjacent
processing.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Koichi Suzuki | 2024-12-06 06:11:49 | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
| Previous Message | Tom Lane | 2024-12-06 05:44:10 | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |