From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench - allow backslash continuations in \set expressions |
Date: | 2016-12-01 08:08:24 |
Message-ID: | alpine.DEB.2.20.1612010907320.24014@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2016-12-01 08:49:47 | Re: Improving RLS planning |
Previous Message | Michael Paquier | 2016-12-01 07:27:42 | Re: Broken SSL tests in master |