From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Erik Rijkers <er(at)xs4all(dot)nl>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) |
Date: | 2017-03-30 15:45:51 |
Message-ID: | 18081.1490888751@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> [...] Aside from cosmetic changes, I've made it behave reasonably for
>> cases where \if is used on portions of a query, for instance
> A small issue I see is that I was planning to add such an if syntax to
> pgbench (well, at least if I succeed in getting boolean expressions and
> setting variables, which is just a maybe), but this kind of if in the
> middle of expression does not make much sense for a pgbench script where
> "if" must be evaluated at execution time, not parse time.
Well, it's not really clear to me why that would be true. If it actually
is impossible to give pgbench equivalent behavior, we'll just have to live
with the discrepancy, but ISTM it could probably be made to work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2017-03-30 15:47:00 | Re: [pgsql-students] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree" |
Previous Message | Andres Freund | 2017-03-30 15:41:14 | Re: Patch: Write Amplification Reduction Method (WARM) |