Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster