Re: [PATCH] two-arg current_setting() with fallback - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] two-arg current_setting() with fallback
Date
Msg-id 13637.1426807636@sss.pgh.pa.us
Whole thread Raw
In response to [PATCH] two-arg current_setting() with fallback  (David Christensen <david@endpoint.com>)
Responses Re: [PATCH] two-arg current_setting() with fallback  (David Christensen <david@endpoint.com>)
List pgsql-hackers
David Christensen <david@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Next
From: Andreas Karlsson
Date:
Subject: Re: patch : Allow toast tables to be moved to a different tablespace