Greg Stark <st...@mit.edu> writes: > Huh, I had assumed this was old behaviour. I didn't realize this was > new with 9.3.
> Considering the thread "pg_get_viewdefs() indentation considered > harmful" I'm beginning to think this was a regression. It results in > some dump files being unnecessarily large and the pg_dump consuming > too much memory and crashing. > Tom liked my suggestion of doing the indentation modulo 40. There are > plenty of other suggestions that can work too, giving up on > indentation after an indent of 40, switching to an indent distance of > 1 if it's more than 10 levels deep, and so on. I think it doesn't > really matter which we choose but we have to do something. And given > this is new behaviour in 9.3 perhaps it should be backported too. I'm still a bit skeptical about this being a catastrophic problem in practice ... but anyway, I thought there were two somewhat different proposals on the table in that thread: 1. Arrange for "x UNION y UNION z ..." to put all the UNION arms at the same indentation level. 2. Change the indentation rules globally, in one or another fashion as Greg mentions above, to prevent ruleutils from ever prepending silly amounts of whitespace. These are not mutually exclusive, and I think we should do both. But it seems we're hung up on exactly which flavor of #2 to do. I would argue that rules such as "reduce the indent step once we're too far over" don't fix the problem, just postpone it. If we're taking this complaint seriously at all then there needs to be a guaranteed maximum indent distance, one way or another. So I'd go for either a modulo-N rule or a hard limit, with some preference for the modulo-N approach. Yeah, it does sound silly at first, but I think it'd preserve readability better than just capping the indent. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers