Re: pgbench - allow backslash-continuations in custom scripts

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench - allow backslash-continuations in custom scripts
Date: 2016-03-21 19:33:53
Message-ID: CA+TgmoZQ7dB1FXPMH1J+rQOGHULSQkSECOAVOdf-9akpM2t0fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 21, 2016 at 3:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Wait, was it really? I'd been thinking it was mostly to continue
>> queries, not metacommands, but maybe I missed the boat.
>
> Nah, you're right, it was about continuing queries. Still, we've had
> complaints about the other thing too, and I think if we're going to
> change anything here, we should change it all in the same release.

Fair enough.

>>> * Allow multiple backslash commands on one line, eg
>>> \set foo 5 \set bar 6
>>> The main reason for that is that psql allows it, and one of the things
>>> we're supposedly trying to do here is reduce the behavioral distance
>>> between psql and pgbench parsing rules.
>
>> This seems to me to be going in the wrong direction.
>
> Um, why exactly? That psql behavior is of really ancient standing, and
> we have not had complaints about it.

I think that's mostly because the psql metacommands are ridiculously
impoverished. I'm guessing that pgbench's expression language is
eventually going to support strings as a data type, for example, and
those strings might want to contain backlashes. There's basically no
value in cramming multiple metacommands onto a single line, but there
is the risk of creating unnecessary lexing or parsing difficulties in
the future.

>>> * Allow backslash commands to span lines, probably by adopting the
>>> rule that backslash immediately followed by newline is to be ignored
>>> within a backslash command. This would not be compatible with psql,
>>> though, at least not unless we wanted to change psql too.
>
>> This might have some point to it, though, if you want to say \set i
>> <incredibly long expression not easily contained on a single line>
>
> Shall I make a patch that allows backslash-newline to be handled this way
> in both psql and pgbench backslash commands? At least in psql, there
> would be no backwards compatibility problem, since right now the case
> just fails:
>
> regression=# \set x y \
> Invalid command \. Try \? for help.

I certainly don't object to such a patch, although if it's between you
writing that patch and you getting Tomas Vondra's multivariate
statistics stuff committed, I'll take the latter. :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2016-03-21 19:38:40 Re: Choosing parallel_degree
Previous Message David G. Johnston 2016-03-21 19:25:57 Re: Request - repeat value of \pset title during \watch interations