Re: [GENERAL] psql \pset pager

Steve Crawford wrote:
> My fingers sometimes run on "autoappend semicolon" mode and I end up
> typing "\pset pager always;" instead of "\pset pager always". No error
> is returned, short (but wide) output is not routed to the pager, and I
> have to back up and correct the \pset pager command. After some
> experimentation, I found that any unrecognized string sets the pager to
> be used for long output:
>
> steve=> \pset pager on;
> Pager is used for long output.
>
> steve=> \pset pager off;
> Pager is used for long output.
>
> steve=> \pset pager always;
> Pager is used for long output.
>
> steve=> \pset pager occasionally
> Pager is used for long output.
>
> steve=> \pset pager at random
> Pager is used for long output.
> \pset: extra argument "random" ignored
>
> The above commands set the pager to be used for long output regardless
> of the prior setting. Bad input doesn't generate errors except in the
> case where there are too many parameters.
>
> I didn't find this documented. Is the acceptance of bad input by design
> or an oversight?
>
> Also, what would be the feasibility of having psql route output to the
> pager if the output is too long or too _wide_? I end up with too wide at
> least as often as too long.

[ moved to hackers list]

I looked at the psql code and found:

bool
ParseVariableBool(const char *val)
{
if (val == NULL)
return false; /* not set -> assume "off" */
if (pg_strcasecmp(val, "off") == 0)
return false; /* accept "off" or "OFF" as true */

/*
* for backwards compatibility, anything except "off" or "OFF" is
* taken as "true"
*/
return true;
}

So, I think the answer is that we have the current behavior because of
backward compatibility. Perhaps we should be more strict in
ParseVariableBool(), perhaps only allowing true/false and on/off.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +