Re: pg_get_triggerdef in pg_dump

OK, added to TODO:

Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql

Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into contrib
makes sense.

---------------------------------------------------------------------------

Andreas Pflug wrote:
> Tom Lane wrote:
>
> >
> >I recall objecting to someone who wanted to remove "unnecessary"
> >parentheses, but I can't see any risk in inserting unnecessary
> >whitespace.
> >
> That "someone" was me indeed, and as I mentioned the code is completely
> separated from the code that pg_dump uses. Thus, there's *no way* that
> this could break backup integrity. I consider these original functions
> as pg_dump helper functions, not meant to be human readable.
>
> There are *many* parentheses that are not necessary, and the code trying
> to figure out is quite conservative. All is decided in one single
> routine, depending on two parameters only, and thus failing to locate
> several cases when parentheses would be avoidable (not even */ over +-
> will be noticed!).
>
> I've been trying hard to make pgsql as maintainable as mssql, and
> there's only this point left. Any attempts to contribute this so far
> just have been answered with "dunno but there might eventually perhaps
> maybe some problem" without having a look at that function. I feel that
> I am asked to prove the validity of my code, which is as impossible as
> it is for software in general, but I haven't seen any case where my
> solution failed to reproduce correctly. If you know one, tell me. If you
> know a case where my core routine decides falsely, tell me.
>
> What I *really* want is having the original source stored, including
> comments, version info, ... Currently, it's argued that underlying table
> and column might change, braking the view/rule. This could be
> restricted, or source could be dropped (alter table ... cascaded). Is it
> really only me who tries to put complicated views into pgsql and wants
> to understand them 10 days later? We do have an enterprise grade RDBMS,
> don't we?
>
> Regards,
> Andreas
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073