Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Date
Msg-id CADkLM=d40LRKHsJskMVVOm=0wZd2HLOo40hakjXRPYjSSjdZ=Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

In the end, I suspect that teaching all the backslash commands to do
nothing after absorbing their arguments is likely to be the least messy
way to tackle this, even if it makes for a rather bulky patch.


Perhaps, but just glancing at \connect makes me think that for some commands (present or future) the number of args might depend on the value of the first arg, and variable expansion-or-not, backtick execution-or-not could alter the number of apparent args on the line, like this:

\set x 'arg1 arg2'

\if false
    \cmd_that_takes_exactly_two_args :x
\endif 

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] <> join selectivity estimate question