From: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Subject: | Re: Improve documentation regarding custom settings, placeholders, and the administrative functions |
Date: | 2025-02-06 02:36:20 |
Message-ID: | 6ffeeead-0b17-487d-860b-11cc8f18a3aa@Spark |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 20, 2024 at 04:12 +0800, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, wrote:
>
> Mostly I'm pointing out the fact that one can never take the null value to be the actual value of a setting. In terms of current_setting this then establishes the fact that the null value it may return is an error-handling alternative only and not something to be relied upon as being an actual value of the setting.
> - Returns the current value of the+ Returns the current non-null value of the setting <parameter>setting_name</parameter>. If there is no such setting, <function>current_setting</function> throws an error unless <parameter>missing_ok</parameter> is supplied and
Hi,
current_setting() could return NULL when missing_ok is passed, so is it right to say: Returns the current non-null value of the setting <parameter>setting_name</parameter>?
As the doc is for function of current_setting(), and it could return NULL actually.
gpadmin=# \pset null NULL
Null display is "NULL".
gpadmin=# select current_setting('pg_xmen', true);
current_setting
-----------------
NULL
(1 row)
--
Zhang Mingli
HashData
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-02-06 02:49:10 | Re: Improve documentation regarding custom settings, placeholders, and the administrative functions |
Previous Message | Amit Langote | 2025-02-06 02:35:47 | Re: generic plans and "initial" pruning |