Re: pg_dump output portability

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Most of these look like they would break a lot of people --- for
>> example, we can't just arbitrarily change the results of bool_out.

> That wouldn't help anyway.  I meant to add code in pg_dump (and possibly
> the rule recompiler).  That doesn't break anything.

Ah.  But where exactly will you substitute true for 't'?  I don't think
pg_dump necessarily knows enough to apply that transformation.
ruleutils could and probably should do it for bool constants, but that's
only a small part of pg_dump output.

>> You mean you'd rather eliminate the -N behavior, no?  I'd vote for that.

> Yes.  Or at least switch the default to "portable and readable".

Switching the default is definitely fine with me, but I'd lean towards
ripping it out entirely, given that the backend-supplied chunks of stuff
are not going to have extra quotes.  We always tell people "always quote
or never quote" a given identifier; pg_dump scripts ought to follow that
rule.

>> Again, I'm fairly suspicious of this; it seems likely to result in
>> failures to read in the data.  You can't just leave data newlines as-is
>> for example.

> Why not?  You'd end up with

> INSERT ... VALUES ('multi
> line
> literal', 'more data');

> This is accepted by PostgreSQL now, is legal SQL, and is arguably at least
> as readable as octal escape sequences.  (Note I'm not talking about doing
> this in COPY, which is not portable anyway.)

Okay, I missed that context; I was thinking of COPY.  Yeah, in string
literals in INSERT it seems fairly reasonable to do nothing to the data
except double ' and \.  I am a little worried however about
character-set-encoding gotchas.  Hiroshi or Tatsuo might have more
insight here.
        regards, tom lane