Re: BUG #12725: psql: no interpretation of option -F

On Mon, Feb 02, 2015 at 10:24:18AM -0500, Tom Lane wrote:
>hans(at)matfyz(dot)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