> On Mar 19, 2015, at 6:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> 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
In that case, the other thought I had here is that we change the function
signature of current_setting() to be a two-arg form where the second argument
is a boolean "throw_error", with a default argument of true to preserve
existing semantics, and returning NULL if that argument is false. However, I'm
not sure if there are some issues with changing the signature of an existing
function (e.g., with pg_upgrade, etc.).
My *impression* is that since pg_upgrade rebuilds the system tables for a new
install it shouldn't be an issue, but not sure if having the same pg_proc OID
with different values or an alternate pg_proc OID would cause issues down the
line; anyone know if this is a dead-end?
Regards,
David
--
David Christensen
End Point Corporation
da...@endpoint.com
785-727-1171
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
