Re: [PG19] psql backslash commands fail with translated messages and a non UTF-8 client encoding

shihao zhong <zhong950419(at)gmail(dot)com> writes:
>> We should address this case as well, or is it reasonable to ignore it as
>> an edge case?

> I can reproduce it, and I think we should fix it. Guessing the encoding
> gettext uses keeps missing cases.
> v6 does two things. It treats OUTPUT_CHARSET as set if it was set when
> psql started, since gettext keeps using that value.

I thought that it'd be a good idea to push the infrastructure part of
this (ie, inventing addQueryComment) separately, since that step is
bulky, boring, and different between the branches. So I did that,
and now we just need to discuss what logic to put into
addQueryComment. I've attached a v7 to show what remains to do.

I'm not convinced by the OUTPUT_CHARSET handling in v6: it only
detects the situation where OUTPUT_CHARSET is set at the moment we're
trying to output a label. If you are worried that gettext will latch
onto a no-longer-present setting then that's not really good enough.
What I put into v7 was an addition in exec_command_setenv() to
remember if we ever did \setenv OUTPUT_CHARSET. AFAIK that is the
only pathway for psql env vars to change after startup, so that seems
like it ought to be bulletproof.

Having said that, I'm really quite unconvinced that we should be
expending any effort on OUTPUT_CHARSET at all. If someone is using
that to select an encoding that doesn't match psql's locale, they
are going to have lots more problems besides this one, and it's
all self-inflicted damage. So my vote is to rip out all the logic
related to OUTPUT_CHARSET.

The other thing I'm not super pleased about is invoking
pg_get_encoding_from_locale() each time through. That seems like a
moderately expensive operation. I also wonder whether the result
can change intra-run and whether gettext will track it if so.

regards, tom lane