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:
boolParseVariableBool(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 */ /* *
forbackwards 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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
