From: Tom Lane <tgl@sss.pgh.pa.us>
To: Koichi Suzuki <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
In-reply-to: 
 <CABEZHFuqEkpoEf91VkK8A2Gbmcp0ELhYAYz_5J0SRCim=KJwWA@mail.gmail.com>
References: <18735-4acdb3998bb9f2b1@postgresql.org>
 <2572359.1733424649@sss.pgh.pa.us>
 <CABEZHFuqEkpoEf91VkK8A2Gbmcp0ELhYAYz_5J0SRCim=KJwWA@mail.gmail.com>
Comments: In-reply-to Koichi Suzuki <koichi.dbms@gmail.com>
	message dated "Fri, 06 Dec 2024 13:12:50 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2744314.1733461500.1@sss.pgh.pa.us>
Date: Fri, 06 Dec 2024 00:05:00 -0500
Message-ID: <2744315.1733461500@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2744315.1733461500%40sss.pgh.pa.us>
Precedence: bulk

Koichi Suzuki <koichi.dbms@gmail.com> writes:
> Lexical analysis of backshash commands in psql is handled
> by psqlscanslash.l and this module scans iput byte-by-byte, not
> character-by-character.   I'm afraid that the cause of the bug is in
> this part..   Is there any way to make this flex syntax local-dependent?

I think you're mistaken: see the "safe_encoding" hackery in
psqlscan.l (which does also operate for the rules in psqlscanslash.l).
Now it could be that psqlscan.l has been misinformed about the
encoding that's in use, but that wouldn't be its fault.

			regards, tom lane