Re: Fwd: automatic disable unicode line style when terminal is not unicode - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Fwd: automatic disable unicode line style when terminal is not unicode
Date
Msg-id CAFj8pRDhZ6p==B5nWhF2Mub54czWmOACroUYnJAarUjo1cTofA@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: automatic disable unicode line style when terminal is not unicode  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2018-03-04 16:53 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I have to return back to 8bit encoding, and in this old world, the unicode
> borders doesn't work. Sure. It can be simply disabled and forced to ascii.
> What do you think about it?

I don't think we should assume we know what the terminal code will do.
If the line style doesn't actually work, the user will notice and change
the setting quickly enough.  If we try to do it for him, we might break
situations that work fine now.

The sort of situation I have in mind is, for instance, working through
an ssh connection.  IME it's very often the case that the server side
of the connection doesn't really have an accurate idea of the terminal
capabilities or encoding on the user side.  Code that's trying to be
smart just results in less-predictable behavior.

The code is very simply

if (strcmp(nl_langinfo(CODESET), "UTF-8")  != 0)
  do_pset("linestyle", "ascii", &pset.opt, true);

There is another question. With unicode linestyle border we don't respect client encoding when client_encoding is different than unicode. So the result must be broken.

Regards

Pavel



                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Function to track shmem reinit time
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type