Re: pg_dump output portability

Peter Eisentraut <peter_e(at)gmx(dot)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