Re: [HACKERS] Undefined psql variables - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] Undefined psql variables
Date
Msg-id CAKFQuwbk_hOueXSxAR+sS1g3sn_J3qaFz6dQDjQ32Zq-gCvBiw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Undefined psql variables  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: [HACKERS] Undefined psql variables  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
On Mon, Jan 23, 2017 at 10:34 AM, Corey Huinker <corey.huinker@gmail.com> wrote:
I was giving some thought to how psql handles undefined variables.

I would like an option where either psql can provide an alternate value when an undefined variable is referenced, or a way to detect that a specific variable is undefined and replace it with a defined variable.

My first thought thought was to have a
 
\set_if_undefined var_name 'default_value'

​\coalesce var_name [maybe other var names?] 'default_value' --sets the value of var_name to itself or the first defined/non-null result of the subsequent items​.  Probably only useful if you allow expressions.  I have followed the "\if" thread that closely but IIRC that was part of the discussion there.
 

Another idea adding a \pset parameter that would return a specific value when an undefined psql variable is referenced instead of raising an error. Like this:

# select :'x' as value_of_x;
ERROR:  syntax error at or near ":"
LINE 1: select :'x' as value_of_x;
               ^

# \pset variable_default ''
analytics=# select :'x' as value_of_x;
 value_of_x
------------

(1 row)


​-1​

I unconvinced that setting this in the global environment is a good thing.

David J.

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Logical replication launcher's bgworker enabled bydefault, and max_logical_replication_workers
Next
From: Corey Huinker
Date:
Subject: Re: [HACKERS] Undefined psql variables