From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench - allow backslash continuations in \set expressions |
Date: | 2016-11-30 19:20:25 |
Message-ID: | 16470.1480533625@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com> writes:
> On Wed, Nov 9, 2016 at 3:28 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>>>> +1. My vote is for backslash continuations.
>> I'm fine with that!
> Looks good to me also.
I concur that we don't want implicit continuation; that creates too many
special cases and will certainly fail to generalize to other backslash
commands. My gripe with pgbench-set-continuation-1.patch is actually
the latter: I do not like the idea that this works only for \set and
not other backslash commands. I think we should have uniform behavior
across all backslash commands, which probably means implementing this
in psqlscan.l not exprscan.l, which probably means that it would apply
in psql as well as pgbench. But I argue that's a Good Thing.
I certainly don't see that psql needs this less ... try a \copy command
with a complicated SELECT source sometime.
In short, I want to mark this RWF for today and ask for a version that
applies globally to all backslash commands in psql and pgbench.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2016-11-30 19:20:39 | Re: Random number generation, take two |
Previous Message | Alvaro Herrera | 2016-11-30 19:05:18 | Re: Random number generation, take two |