Re: pgbench - allow backslash continuations in \set expressions
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rafia Sabih <rafia.sabih@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2016-12-01T08:08:24Z
Lists: pgsql-hackers
Hello Tom,
> [...]
I definitely agree that having homogeneous continuations on every
backslash commands is better, but this has a cost in code lines and
possible backward compatibilities. This is the kind of thing better
addressed in the initial design rather than long afterwards...
> FWIW, I looked a bit further and concluded that probably psqlscan.l
> doesn't need to be modified; so likely you could do this across all of
> pgbench's commands without touching psql.
Hmmm, I'm a little bit lost, you just asked for that:
>>> In short, I want to [...] ask for a version that applies globally to
>>> all backslash commands in psql and pgbench.
I'm pointing out that this requirements implies that all such commands
share some minimal common lexical structure, higher that the current "pass
every characters up to the next new line".
- what would be the common acceptable requirements?
at least \<nl> = continuation
- maybe \\<nl> is just \<nl> if need be? or not??
- what about simple/double quoted strings (eg in \copy ...)?
or can we say that the continuation preprocessing does not look into
that, and is pretty rough, and that is fine?
- if not, are possible corner case backward incompatibilities introduced
by such feature ok?
> That might be an acceptable compromise for now, though I still think
> that as soon as we have this for pgbench, users will start wanting it in
> psql.
ISTM that you put the case for having them everywhere or nowhere, so I'm
trying to measure the effort implied by the former before deciding what
I'll do.
--
Fabien.
Commits
-
Allow backslash line continuations in pgbench's meta commands.
- cdc2a70470bd 10.0 landed