Обсуждение: BUG #12725: psql: no interpretation of option -F
The following bug has been logged on the website: Bug reference: 12725 Logged by: Hans Ginzel Email address: hans@matfyz.cz PostgreSQL version: 9.4.0 Operating system: Centos 6.5 Description: Hello! There is, in the [doc] that -F is equivalent to \f. But try echo 'SELECT * FROM information_schema.Tables LIMIT 1;' |psql -qnaAF'\t' -Pfooter=off versus cat <<EOF |psql -qnaA -Pfooter=off \f '\t' SELECT * FROM information_schema.Tables LIMIT 1 EOF versus echo 'SELECT * FROM information_schema.Tables LIMIT 1;' |psql -qnaAFF"`echo -e '\t'`" -Pfooter=off It seems that that the command line parameter of the -F option is not interpreted for escape sequences. Please add this. [doc]: http://www.postgresql.org/docs/9.4/static/app-psql.html Best regards Hans
hans@matfyz.cz writes:
> It seems that that the command line parameter of the -F option is not
> interpreted for escape sequences. Please add this.
I think the odds of breaking things would be higher than the odds of
improving anyone's life.
It's not unusual for command line parameters to be interpreted more
strictly than the "same" parameters within SQL; an example is that
table names in pg_dump switches, or database names in just about any
client's command line, are taken literally rather than case-folded.
There are a number of reasons for this, one being that the quoting
conventions of a shell don't mix very nicely with SQL's conventions,
and another being that if the parameter is coming from some shell
script's internal variable you don't really want to insist on it
having to be re-quoted to be preserved. That second argument seems
to apply to the arguments of -F and related switches, too.
Between that, and the question of backwards compatibility, and the
existence of easy workarounds, I don't think we should change this.
regards, tom lane
On Mon, Feb 02, 2015 at 10:24:18AM -0500, Tom Lane wrote:
>hans@matfyz.cz writes:
>> It seems that that the command line parameter of the -F option is not
>> interpreted for escape sequences. Please add this.
>
>I think the odds of breaking things would be higher than the odds of
>improving anyone's life.
I am sorry, but I disagree. I cannot immagine someone who wants
literal \t as delimiter.
But I can imagine anyone who wants \n literaly for NULLs (-Pnull='\n').
But consensus is '\N' to distinguiahs from new line.
You can
* schedule the repair to 9.5 or 10.0,
* or you can add option like --dont-interpret-escape-seq-in-sperator
* or you can add commandline/configuration option
like --backward-compatible [= version_number]
* or an positive one: --moderm-postgres where such mistakes would be repaired
and the level of âconservatismâ would be lowered.
Workaround is ugly and is almost not possible under Windows
unless tab completition is switched off
(http://serverfault.com/questions/210978/escape-tab-in-cmd-exe).
There must be a way how to make postgres more friendly.
With such grousy approach newcomers are demotivated to write patches.
>It's not unusual for command line parameters to be interpreted more
>strictly than the "same" parameters within SQL; an example is that
>table names in pg_dump switches, or database names in just about any
>client's command line, are taken literally rather than case-folded.
>There are a number of reasons for this, one being that the quoting
>conventions of a shell don't mix very nicely with SQL's conventions,
>and another being that if the parameter is coming from some shell
>script's internal variable you don't really want to insist on it
>having to be re-quoted to be preserved.
What would be exported if I will have tables
"MY_TABLE", "My_Table" and "my_table", which is ANSI correct,
and I invoke âpg_dump --table='My_Table'â in sh-like shell?
> That second argument seems
> to apply to the arguments of -F and related switches, too.
IMHO, it is an independent argument/problem â handling of
escaped characters ('\t') in postgres vs. quoting table names
in a shell = escaping the double quote character (") in shells.
Regards
Hans Ginzel
>Between that, and the question of backwards compatibility, and the
>existence of easy workarounds, I don't think we should change this.
>
> regards, tom lane
Hans Ginzel wrote > On Mon, Feb 02, 2015 at 10:24:18AM -0500, Tom Lane wrote: >> > hans@ > writes: >>> It seems that that the command line parameter of the -F option is not >>> interpreted for escape sequences. Please add this. >> >>I think the odds of breaking things would be higher than the odds of >>improving anyone's life. >=20 > I am sorry, but I disagree. I cannot immagine someone who wants > literal \t as delimiter. > But I can imagine anyone who wants \n literaly for NULLs (-Pnull=3D'\n'). > But consensus is '\N' to distinguiahs from new line. >=20 > You can > * schedule the repair to 9.5 or 10.0, > * or you can add option like --dont-interpret-escape-seq-in-sperator > * or you can add commandline/configuration option > like --backward-compatible [=3D version_number] > * or an positive one: --moderm-postgres where such mistakes would be > repaired > and the level of =E2=80=9Cconservatism=E2=80=9D would be lowered. > Workaround is ugly and is almost not possible under Windows > unless tab completition is switched off > (http://serverfault.com/questions/210978/escape-tab-in-cmd-exe). Any solution would need to continue treating existing syntax the same - so adding flags to enable the existing behavior is not really viable. How about allowing passing in the SQL "escape me" literal: -F E'\t' David J. -- View this message in context: http://postgresql.nabble.com/BUG-12725-psql-n= o-interpretation-of-option-F-tp5836358p5836435.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
David G Johnston <david.g.johnston@gmail.com> writes:
> Any solution would need to continue treating existing syntax the same - so
> adding flags to enable the existing behavior is not really viable.
Yeah, that's not gonna fly.
> How about allowing passing in the SQL "escape me" literal:
> -F E'\t'
Meh. That's still going to amount to an incompatible change, because
that's valid syntax now, even if you think it's a case people are unlikely
to be using. Also, as written the quotes would get stripped by the shell,
making it even less clearly distinguishable from other cases.
This whole business of trying to devise syntax that both follows typical
SQL escape behavior and plays nicely with shell quoting behavior is a
mess. As I mentioned, we gave up on it years ago with regards to
identifier case folding (but not for lack of having tried). I'm not
really eager to spend effort on it for this case, especially not when
there are multiple alternative solutions available already.
regards, tom lane