Re: pg_get_triggerdef in pg_dump

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