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