| 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: | Whole Thread | Raw Message | 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 |