Re: BUG #18057: unaccent removes intentional spaces

Michael Paquier <michael(at)paquier(dot)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