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

From Fabien COELHO
Subject Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Date
Msg-id alpine.DEB.2.20.1702031421490.4856@lancre
Whole thread Raw
In response to Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
>> 2. Inside an \if block \q should be given precedence and cause a direct 
>> exit of psql (or at the very least exit the if block(s)), as in regular SQL 
>> statements (compare: 'select * from t \q' which will immediately exit psql 
>> -- this is good. )
>
> One use case if to be able to write "\if ... \q \endif" in scripts. If \q is 
> always executed, then the use case is blown. I cannot think of any language 
> that would execute anything in a false branch. So Ctrl-C or Ctrl-D is the way 
> out, and \if control must really have precedence over its contents.

After giving it some more thoughts, a possible solution could be to have a 
"\exit [status]" which could be ignored (there has been some talk about 
that one), and have \q which is not, but I would find it weird and error 
prone for the user. As already said, \if use-case is not about interactive 
psql.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] patch: optimize information_schema.constraint_column_usage