Re: pgbench - allow backslash continuations in \set expressions
| От | Rafia Sabih |
|---|---|
| Тема | Re: pgbench - allow backslash continuations in \set expressions |
| Дата | |
| Msg-id | CAOGQiiOhUwJcoa0zzO2NstAVtV7_EQno0LRBNC6zF7DT6j-LtQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgbench - allow backslash continuations in \set expressions (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: pgbench - allow backslash continuations in \set
expressions
|
| Список | pgsql-hackers |
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. In general, this new approach is likely to create confusions in such cases. 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.
On Tue, Nov 1, 2016 at 4:23 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
Attached patch does what is described in the title, hopefully. Continuations in other pgbench backslash-commands should be dealt with elsewhere...
Also attached is a small test script.
Here is another approach, with "infered" continuations: no backslash is needed, the parsing is pursued if the last token of the line cannot end an expression (eg an operator) or if there is an unclosed parenthesis.
I think that backslashes are less surprising for the classically minded user, but this one is more fun:-) Also, this version changes a little more the scanner because on each token the next state (continued or not) must be decided.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: