Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME,FALLBACK)
От | Nico Williams |
---|---|
Тема | Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME,FALLBACK) |
Дата | |
Msg-id | 20171101180237.GO4496@localhost обсуждение исходный текст |
Ответ на | [HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK) (David Christensen <david@endpoint.com>) |
Ответы |
Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME,FALLBACK)
Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME,FALLBACK) |
Список | pgsql-hackers |
On Thu, Mar 19, 2015 at 05:41:02PM -0500, David Christensen wrote: > 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.: There already _is_ a two-argument form of current_setting() that yours somewhat conflicts with: current_setting(setting_name [, missing_ok ]) https://www.postgresql.org/docs/current/static/functions-admin.html I often use coalesce(current_setting(setting_name, true), default_value_here) as an implementation of current_setting() with a default value. You could treat booleans as the second argument as a missing_ok argument instead of a default value, since _currently_ current_setting() only returns TEXT. But if ever GUCs are allowed to have values of other types, then your two-argument current_setting() will conflict with boolean GUCs. There are several ways to prevent such a future conflict. Here are some: - make a two-argument current_setting() for boolean GUCs treat the second argument as a default value (since there are nosuch GUCs today, this won't break anything) - use a new function name - use a three-argument current_setting() The third option seems very lame to me. So I'd argue for either of the other two. Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: