From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench - allow backslash continuations in \set expressions |
Date: | 2016-11-01 12:26:14 |
Message-ID: | alpine.DEB.2.20.1611011311080.9978@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Rafia,
> Well with this new approach, the example you gave previously for better
> readability:
>
>> \set bid
>> CASE WHEN random(0, 99) < 85
>> THEN :tbid
>> ELSE :abid + (:abid >= :tbid)
>> END
>
> will give error at the first line.
Indeed you are right for the patch I sent, but it is ok if the initial
state is COEX, i.e. it does not allow an empty expression.
> In general, this new approach is likely to create confusions in such
> cases.
See attached version.
> As an end-user one needs to be real careful to check what portions have
> to split between lines. Keeping this in mind, I'd prefer the previous
> approach.
I will not fight over this one. I like it in "scala", though, and I find
it rather elegant, especially as backslashes are quite ugly.
Another reason not to take it is that it would be much harder to have that
in psql as well.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-set-infered-continuation-2.patch | text/x-diff | 3.6 KB |
cont2.sql | application/x-sql | 93 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Julian Markwort | 2016-11-01 12:58:41 | Re: [PATCH] pgpassfile connection option |
Previous Message | Etsuro Fujita | 2016-11-01 12:20:09 | Typo in comment in contrib/postgres_fdw/deparse.c |