Re: very long record lines in expanded psql output

On 2022-Jul-25, Andrew Dunstan wrote:

> Committed. There were a couple of bits missing, which I filled in, and I
> changed the behaviour when the option is given without an argument, so
> that instead of resetting it the current value is shown, similarly to
> how most pset options work.

I was translating the new messages introduced by this commit, and
decided to unify them.  While doing so, I notice that the feature
misbehaves when you give it a string value that doesn't match any valid
value: it just resets the value to 0, which is entirely the wrong thing.
For other settings, we first verify that the given value is valid, and
only then we change the setting.

So I came up with the attached.  While at it, I noticed that we have
other uses of atoi() there, most notably pager_min_lines.  My first
impulse was to just to do the same as for xheader_width, namely to test
whether the atoid result is zero, and not change in that case.  But then
I noticed we're already using variables.c facilities, so I decided to do
likewise; this results in simpler code.  So we're now stricter, because
variables.c rejects trailing junk after the number.  (123asd was
previously parsed as 123, now it's an error.)


There remain atoi uses in this code, and aside from the atoi()-induced
behavior of making any non-number input set it to 0, it does stuff like

=# \pset border 65538asd
Border style is 2.

because border style is short int, so this value overflows it.  Same
happens with 'columns'.  However, this is all very old code and nobody
seems to have complained.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"¿Cómo puedes confiar en algo que pagas y que no ves,
y no confiar en algo que te dan y te lo muestran?" (Germán Poo)