Re: pgbench - allow backslash continuations in \set expressions
От | Tom Lane |
---|---|
Тема | Re: pgbench - allow backslash continuations in \set expressions |
Дата | |
Msg-id | 8351.1480619624@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgbench - allow backslash continuations in \set expressions (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pgbench - allow backslash continuations in \set expressions
|
Список | pgsql-hackers |
Fabien COELHO <coelho@cri.ensmp.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
В списке pgsql-hackers по дате отправления: