Prettification versus dump safety

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

(1) change pg_dump to not prettify trigger definitions at all, or
(2) change pg_get_triggerdef from the submitted patch so that it
doesn't reduce parenthesization even in "pretty" mode.

Or somebody could bite the bullet and decouple formatting from
parenthesization decisions in ruleutils.c. That's not going to be
me, though.

Comments, preferences?

Apply (2), and add the decoupling to the official todo list.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200911201315
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksG3NEACgkQvJuQZxSWSsiIjgCg1u1oZqXGsM/ToBYH6OCBMcDt
yXUAoK8xquH56UerP6AQl7bVxhMhPyyH
=yuZ4
-----END PGP SIGNATURE-----

Tom Lane wrote:

In testing the TRIGGER WHEN patch, I notice that pg_dump is relying on
pg_get_triggerdef(triggeroid, true) (ie, "pretty" mode) to dump
triggers. This means that trigger WHEN conditions will be dumped
without adequate parenthesization to ensure they are interpreted the
same way when loaded into future PG versions. That's not acceptable.

The easy ways out of this are
(1) change pg_dump to not prettify trigger definitions at all, or
(2) change pg_get_triggerdef from the submitted patch so that it
doesn't reduce parenthesization even in "pretty" mode.

The pretty option was explicitely never intended for pg_dump use.
When pg_dump is used to create a future version proof dump, it shouldn't
use the pretty option, when used to create some schema scripts for
exernal editing it may be enabled. I propose to invent a cmd line option
for that (maybe as "prettified plain text" output format).

Regards,
Andreas

Andreas Pflug <pgadmin@pse-consulting.de> writes:

Tom Lane wrote:

The easy ways out of this are
(1) change pg_dump to not prettify trigger definitions at all, or
(2) change pg_get_triggerdef from the submitted patch so that it
doesn't reduce parenthesization even in "pretty" mode.

The pretty option was explicitely never intended for pg_dump use.

Yeah. I went with (1) because it's something we can undo in future
on the pg_dump side. The alternative is to immortalize an arbitrary
deviation of pg_get_triggerdef's pretty-fying behavior compared to
every other ruleutils.c function.

regards, tom lane