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

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.