From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: automatic disable unicode line style when terminal is not unicode |
Date: | 2018-03-04 16:19:27 |
Message-ID: | CAFj8pRDhZ6p==B5nWhF2Mub54czWmOACroUYnJAarUjo1cTofA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2018-03-04 16:53 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-03-04 16:59:42 | Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type |
Previous Message | Tomas Vondra | 2018-03-04 16:17:32 | Re: Function to track shmem reinit time |