Improve documentation for current_setting function
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t76417psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 28, 2026 at 01:40 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t76417_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t76417_2 && git checkout t76417_2Patchset v2 (message #2) is on t76417_2
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/11/functions-admin.html
Description:
Hi.
Doc is not clear about what is returned if current_setting(
'app.not_existent', true ) is called.
Does it return empty string '', because return type is 'text' or it return
NULL, because 'app.not_existent' does not exist
Thank you.
On Wed, Feb 20, 2019 at 12:59:45PM +0000, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/11/functions-admin.html
Description:Hi.
Doc is not clear about what is returned if current_setting(
'app.not_existent', true ) is called.Does it return empty string '', because return type is 'text' or it return
NULL, because 'app.not_existent' does not exist
Testing shows:
SELECT current_setting('asdf', true);
current_setting
-----------------
\pset null (null)
SELECT current_setting('asdf', true);
current_setting
-----------------
--> (null)
How do you like the attached patch, which clarifies this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Hello Bruce,
How do you like the attached patch, which clarifies this?
in which case a missing parameter returns
! NULL.
not always. It can be NULL or empty string. It depends if the current
session is new or after finished transaction which makes 'local' changes
to setting
Take into account these steps: /messages/by-id/15646-0d3caee9f6266f60@postgresql.org
From my user point of view. if the boot value before transaction was
NULL then after transaction it MUST stay NULL and not empty string.
This will be consistent with that if I open new parallel session it
will return NULL.
Also I see NULL value (if setting was not defined) is useful.
Also this:
set_config( 'my.name', NULL )
must set 'my.name' to NULL or must issue warning about NULL is turned
into empty string.
Personally I dislike that NULL is converted to empty string. This
looks ugly. =(
--
Best regards,
Eugen Konkov
On Fri, Feb 22, 2019 at 11:43:54AM +0200, Eugen Konkov wrote:
Hello Bruce,
How do you like the attached patch, which clarifies this?
in which case a missing parameter returns
! NULL.not always. It can be NULL or empty string. It depends if the current
session is new or after finished transaction which makes 'local' changes
to settingTake into account these steps: /messages/by-id/15646-0d3caee9f6266f60@postgresql.org
Yes, I saw that recent thread.
From my user point of view. if the boot value before transaction was
NULL then after transaction it MUST stay NULL and not empty string.This will be consistent with that if I open new parallel session it
will return NULL.Also I see NULL value (if setting was not defined) is useful.
Also this:
set_config( 'my.name', NULL )
must set 'my.name' to NULL or must issue warning about NULL is turned
into empty string.Personally I dislike that NULL is converted to empty string. This
looks ugly. =(
Understood.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +