From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: martin@schlossarek.me, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18057: unaccent removes intentional spaces
In-reply-to: <ZOFW6ZBerH/IBoTC@paquier.xyz>
References: <18057-62712cad01bd202c@postgresql.org>
 <ZNwRq4nV7CBXAoJN@paquier.xyz> <ZN8NUpx2f9pB+F/g@paquier.xyz>
 <2334732.1692462604@sss.pgh.pa.us> <ZOFW6ZBerH/IBoTC@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sun, 20 Aug 2023 08:57:29 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2399065.1692490106.1@sss.pgh.pa.us>
Date: Sat, 19 Aug 2023 20:08:26 -0400
Message-ID: <2399066.1692490106@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2399066.1692490106%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Aug 19, 2023 at 12:30:04PM -0400, Tom Lane wrote:
>> Yeah, we could extend the parsing rules that way.  It would break
>> any rules files that currently use double quote as a plain character,
>> but it seems unlikely that there are any.  In any case, as long as
>> this wasn't back-patched I think such a change would be acceptable.

> Okay, thanks.  Note that we do use double-quotes as a translated
> character in a few cases, but as long as these are only handled as a
> single character we could be OK.

Oh, shame on me for not actually looking into unaccent.rules :-(
That does make it more complicated, although I think it's still the
case that an incompatible change could be OK.

> Or actually, wouldn't it be better
> to always force escaping even for double quotes listed as single
> characters?

I was envisioning following SQL identifier rules, that is you double
the double quote.  Then the existing " entries would have to become
"""", which isn't much fun.  But what you're suggesting would make
both " and \ into magic characters, doubling the chance of problems
with existing rules files.

We could perhaps allow standalone " to still be considered valid,
but that adds ambiguity that I think we'd eventually regret.
For example, what is the interpretation of

"	"

Is that a (rather useless) translation of " to itself, or is it
a command to delete tab characters?  So I think a clean break
would be better.

			regards, tom lane