Re: pgbench - allow backslash continuations in \set expressions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench - allow backslash continuations in \set expressions
Date
Msg-id alpine.DEB.2.20.1612010907320.24014@lancre
Whole thread Raw
In response to Re: pgbench - allow backslash continuations in \set expressions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgbench - allow backslash continuations in \set expressions
List 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
notlook 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.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Broken SSL tests in master
Next
From: Dean Rasheed
Date:
Subject: Re: Improving RLS planning