Re: [PATCH] two-arg current_setting() with fallback

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Christensen <david(at)endpoint(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] two-arg current_setting() with fallback
Date: 2015-03-19 23:27:16
Message-ID: 13637.1426807636@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Christensen <david(at)endpoint(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2015-03-19 23:33:18 Re: patch : Allow toast tables to be moved to a different tablespace
Previous Message Tom Lane 2015-03-19 23:19:02 Re: "cancelling statement due to user request error" occurs but the transaction has committed.