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

From Daniel Verite
Subject Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Date
Msg-id 9cdc09f7-8e5c-43c9-9c00-2e3bbb69b9ef@manitou-mail.org
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
    Tom Lane wrote:

> OT_WHOLE_LINE is not what you want because that results in verbatim
> copying, without variable expansion or anything

But if we want to implement "\if defined :foo" in the future
isn't it just what we need?

Also we could leave open the option to accept an SQL expression
here. I expect people will need SQL as the evaluator in a lot of cases.
So far we need to do that:
 SELECT sql_expr ... AS varname \gset \if :varname ... \endif

Surely users will wonder right away why they can't write it like this
instead:
 \if (sql_expr) ... \endif

There's a precedent with \copy accepting a query inside parentheses,
using OT_WHOLE_LINE.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Two phase commit in ECPG
Next
From: Michael Paquier
Date:
Subject: [HACKERS] Re: Authentication tests, and plain 'password' authentication with aSCRAM verifier