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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073