Thread: pg_dump pretty_print
Atached is a patch to allow pretty printing of system objects (constraints, indexes, rules, and views) when doing a pg_dump via a --pretty-print flag along with a warning in the docs to be careful about doing so :) -- Greg Sabino Mullane greg@turnstep.com greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8 200701191958 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
Attachment
Greg Sabino Mullane <greg@turnstep.com> writes:
> Atached is a patch to allow pretty printing of system objects
> (constraints, indexes, rules, and views) when doing a pg_dump via a
> --pretty-print flag along with a warning in the docs to be careful about
> doing so :)
Why exactly is that a good idea? Seems like a foot-gun with marginal
usefulness. If you want to look at things "pretty", the psql \d
commands are the tool to use.
regards, tom lane
Greg Sabino Mullane wrote: > Atached is a patch to allow pretty printing of system objects > (constraints, indexes, rules, and views) when doing a pg_dump via a > --pretty-print flag along with a warning in the docs to be careful > about doing so :) Could you provide a less hand-waving specification of this feature? At the moment it sounds like "This option does something fun, but we're not sure what it is." -- Peter Eisentraut http://developer.postgresql.org/~petere/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Eisentraut asked: > Could you provide a less hand-waving specification of this feature? At > the moment it sounds like "This option does something fun, but we're > not sure what it is. Sure. Perhaps after I manage to convince Tom of its usefullness. :) I can expand on what "pretty" is and add a warning akin to the one for --tables. Tom Lane asked: > Why exactly is that a good idea? Seems like a foot-gun with marginal > usefulness. If you want to look at things "pretty", the psql \d > commands are the tool to use. Because sometimes all you have is access to the dump file, or because you want to save/view a historical record; in both cases it is very hard to actually read the input when it's crammed into a single line with minimal whitespacing. Since we already do make some concessions as far as making the dump file human-readable, offering this as an *optional* flag seems (mostly) harmless. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200701221450 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFtRV1vJuQZxSWSsgRAm4iAJ9lro5hvpbYHQB6fM06uH7wUHzLlwCgpamm wUpTmpqn4JbcEGsHmM1OTPQ= =HrpY -----END PGP SIGNATURE-----
Am Montag, 22. Januar 2007 20:53 schrieb Greg Sabino Mullane: > Since we already do make some concessions as far as > making the dump file human-readable, offering this as an *optional* flag > seems (mostly) harmless. The harm here is that under undefined circumstances a dump file will not be a proper and robust representation of the original database, which would add significant confusion and potential for error. -- Peter Eisentraut http://developer.postgresql.org/~petere/
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Peter Eisentraut replied: > The harm here is that under undefined circumstances a dump file > will not be a proper and robust representation of the original > database, which would add significant confusion and potential for error. What "undefined circumstances" are we talking here? If there is a chance that pg_get_viewdef and company do not output a version that can be read again by the database because we simply changed the whitespace, that sounds like a serious bug to be fixed, not a reason to reject this optional flag. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200701251003 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFuXd2vJuQZxSWSsgRA9VDAJ9S1b+4DJomO3Bmij4wvida9wtgfgCeID16 qeoNrrehtTGIeJeL8T+mx9M= =VecV -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Peter Eisentraut replied:
>> The harm here is that under undefined circumstances a dump file
>> will not be a proper and robust representation of the original
>> database, which would add significant confusion and potential for error.
> What "undefined circumstances" are we talking here? If there is a chance
> that pg_get_viewdef and company do not output a version that can be
> read again by the database because we simply changed the whitespace, that
> sounds like a serious bug to be fixed, not a reason to reject this
> optional flag.
The original definition of the prettyprint flag was that it'd produce a
version that was nice to look at but not guaranteed to parse back
exactly the same; in particular it might omit parentheses that perhaps
were really needed to ensure the same parsing. (I think there might be
some other issues too ... but whitespace is NOT one of them.) It's
possible that the current prettyprint code is smart enough to never make
such an error --- and then again it's possible that it isn't. Like
Peter, I've not got much confidence in that code, and don't want to
trust pg_dump's correctness to it.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Tom Lane wrote: > The original definition of the prettyprint flag was that it'd produce a > version that was nice to look at but not guaranteed to parse back > exactly the same; in particular it might omit parentheses that perhaps > were really needed to ensure the same parsing. (I think there might be > some other issues too ... but whitespace is NOT one of them.) It's > possible that the current prettyprint code is smart enough to never make > such an error --- and then again it's possible that it isn't. Like > Peter, I've not got much confidence in that code, and don't want to > trust pg_dump's correctness to it. Can we perhaps add to the TODO to get the pretty print functions audited and tested out? I'm sure people are already using the pretty print option today via psql so it seems like this should be a high priority. Plus of course I'd like to see it added to pg_dump once Peter, yourself, and others have more confidence in it working as one would expect. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200701301509 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFv6YcvJuQZxSWSsgRA1ujAKDqfH1lAUcba0ce8wBjN/PIRzfNxACgnVWf XnusK0UcywWnaBDF6KE/x4E= =WoFo -----END PGP SIGNATURE-----