David Christensen <da...@endpoint.com> writes:
> The two-arg form of the current_setting() function will allow a
> fallback value to be returned instead of throwing an error when an
> unknown GUC is provided. This would come in most useful when using
> custom GUCs; e.g.:
> -- errors out if the 'foo.bar' setting is unset
> SELECT current_setting('foo.bar');
> -- returns current setting of foo.bar, or 'default' if not set
> SELECT current_setting('foo.bar', 'default')
> This would save you having to wrap the use of the function in an
> exception block just to catch and utilize a default setting value
> within a function.
That seems kind of ugly, not least because it assumes that you know
a value that couldn't be mistaken for a valid value of the GUC.
(I realize that you are thinking of cases where you want to pretend
that the GUC has some valid value, but that's not the only use case.)
ISTM, since we don't allow GUCs to have null values, it'd be better to
define the variant function as returning NULL for no-such-GUC. Then the
behavior you want could be achieved by wrapping that in a COALESCE, but
the behavior of probing whether the GUC is set at all would be achieved
with an IS NULL test.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
