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 <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
