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.
I recall objecting to someone who wanted to remove "unnecessary" parentheses, but I can't see any risk in inserting unnecessary whitespace.
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
