Re: pgbench - allow backslash continuations in \set expressions

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.

In response to

Responses

Browse pgsql-hackers by date

  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