Обсуждение: 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:
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. +

Bruce Momjian <bruce@momjian.us> writes:
> 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.

If we're going to change it, we should make it match GUC's parse_bool,
which has had some actual thought put into it.
        regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > 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.
> 
> If we're going to change it, we should make it match GUC's parse_bool,
> which has had some actual thought put into it.

Good idea.  Do I copy the C code into /psql or somehow share the
function?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> If we're going to change it, we should make it match GUC's parse_bool,
>> which has had some actual thought put into it.

> Good idea.  Do I copy the C code into /psql or somehow share the
> function?

Just copy it --- it's not large enough to be worth doing something like
inventing a /port module for, and besides it's not clear that you want
exactly the same API.
        regards, tom lane