| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PSQL commands: \quit_if, \quit_unless |
| Date: | 2016-12-16 17:40:22 |
| Message-ID: | 27959.1481910022@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> So I think it would be reasonable for somebody to implement \if,
> \elseif, \endif first, with the argument having to be, precisely, a
> single variable and nothing else (not even a negator). Then a future
> patch could allow an expression there instead of a variable. I don't
> think that would be any harder to review than going all the way to #5
> in one shot, and actually it might be simpler.
This seems like a reasonable implementation plan to me, not least because
it tackles the hard part first. There's no doubt that we can build an
expression evaluator, but I'm not entirely sure how we're going to wedge
conditional eval or loops into psql's command reader.
(Or in other words, let's see \while ... \endloop in the minimal proposal
as well, or at least a sketch of how to get there.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2016-12-16 17:40:29 | Re: PSQL commands: \quit_if, \quit_unless |
| Previous Message | Andres Freund | 2016-12-16 17:38:18 | Re: Creating a DSA area to provide work space for parallel execution |