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=chgrfWE3KtH_4i3QjSzicG0+cp3qDZ7-P4p3EDAuYZ2w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers

(1) document that \if-related commands MUST be on their own
    line (i.e. like cpp #if directives?).

I have no opinion on whether \if-related comments must be on their own line, though I coded as if that were the case.

I want to point out that the goal down the road is to allow rudimentary expressions beyond just 'will this string cast to boolean true'.

For example, in the earlier thread "Undefined psql variables", I proposed a slash command that would test if a named psql var were defined, and if not then assign it a value.  

Tom suggested leveraging if-then infrastructure like this

     \if not defined(x)
      \set x y
     \fi

Which would be great. I ask that whatever we decide in terms of how much more input we read to digest the expression allow for constructs like the one above.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Next
From: "David G. Johnston"
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)