Thread: current_setting returns 'unset'

The function current_setting returns 'unset' if a parameter is not set.  
Should it not return null?  This is not documented, so I guess this just 
arose out of the implementation, or is this intentional?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:
> The function current_setting returns 'unset' if a parameter is not set.  
> Should it not return null?  This is not documented, so I guess this just 
> arose out of the implementation, or is this intentional?

That's because SHOW does the same thing.  SHOW has a little problem in
that it can't readily show the difference between "null" and an empty
string, so while I find the behavior pretty ugly, I don't have a better
idea.

The question thus is do you want the function behaving differently from
SHOW.  Returning NULL is probably better from a programming point of
view, but it'd be inconsistent with the command.
        regards, tom lane

Am Dienstag, 10. Januar 2006 16:01 schrieb Tom Lane:
> That's because SHOW does the same thing.  SHOW has a little problem in
> that it can't readily show the difference between "null" and an empty
> string, so while I find the behavior pretty ugly, I don't have a better
> idea.

Since SHOW is primarily for "showing", I'd expect that that user can apply the 
visualization tweaks that the frontend provides, for instance \pset in psql, 
to tell apart null values and empty strings.  Not that "unset" is a typical 
value for string parameters, but you can see where I might go here.

Moreover, the unset state shouldn't exist at all.  No parameter can behave 
reasonably if unset behaved differently from an empty string.  Explicitly 
assigning an unset state doesn't work.  So it seems that for all external 
communication, an unset string parameter should simply display the empty 
string.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> The function current_setting returns 'unset' if a parameter is not 
> set.

> This is not documented,

It is documented to produce equivalent output as the sql SHOW command. 
Although the reference page for SHOW does not specifically address 
parameters that are not set, it does have one in the example at the bottom.

> so I guess this just arose out of the implementation, or is this intentional?

The implementation was based on infrastructure already existing for
SHOW, so this is an artifact of that implementation. In the case of a 
string variable, _ShowOption() returns "unset" when a parameter is not 
set, and that gets passed all the way back.

Joe

Peter Eisentraut <peter_e@gmx.net> writes:
> Moreover, the unset state shouldn't exist at all.  No parameter can behave 
> reasonably if unset behaved differently from an empty string.  Explicitly 
> assigning an unset state doesn't work.  So it seems that for all external 
> communication, an unset string parameter should simply display the empty 
> string.

I wouldn't object to that, but my recollection is that that was once the
behavior, and somebody insisted it was bad.
        regards, tom lane