| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, 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 19:13:44 |
| Message-ID: | 8351.1480619624@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> In psql, if backslash followed by [CR]LF is interpreted as a
>> continuation symbol, commands like these seem problematic
>> on Windows since backslash is the directory separator:
>>
>> \cd \
>> \cd c:\somepath\
>>
>> Shell invocations also come to mind:
>> \! dir \
> Thanks for pointing out these particular cases. I was afraid of such
> potential issues, hence my questions...
Those look like nasty counterexamples, but I think they are not, because
they don't work today. What you get is
regression=# \cd \
Invalid command \. Try \? for help.
AFAICT you would need to write it
regression=# \cd '\\'
\cd: could not change directory to "\": No such file or directory
(That's on Unix of course, on Windows I'd expect it to succeed.)
The reason for this is that psql already has a policy that an unquoted
backslash begins a new backslash command on the same line. Since
there is no command named backslash-return, this is available syntax
that can be repurposed in the direction we want.
I believe that we need to do basically the same thing in pgbench, and
I'm fine with that because I think we should have an overall policy of
synchronizing the psql and pgbench metacommand syntaxes as best we can.
This will at some point necessitate invention of a quoting rule for
pgbench metacommand arguments, so that you can write a backslash as part
of an argument when you need to. We might not need to do that today
(as I'm not sure there are any use-cases for one), but maybe it'd be best
to just bite the bullet and put it in.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-12-01 19:18:00 | Re: Parallel safety of CURRENT_* family |
| Previous Message | 5bih4k+4jfl6m39j23k | 2016-12-01 19:06:24 | Parallel safety of CURRENT_* family |