Jeroen Ruigrok/asmodai wrote:
>Check constraints: "bugs_severity_cstr" ((bug_severity =
>'blocker'::character varying) OR (bug_severity = 'critical'::character
>varying) OR (bug_severity = 'major'::character varying))
>
>If you have even more choices there (as Bugzilla does) you even get:
>
>CONSTRAINT bugs_severity_cstr CHECK ((((((((bug_severity =
>'blocker'::character varying) OR (bug_severity = 'critical'::character
>varying)) OR (bug_severity = 'major'::character varying)) OR
>(bug_severity = 'normal'::character varying)) OR (bug_severity =
>'minor'::character varying)) OR (bug_severity = 'trivial'::character
>varying)) OR (bug_severity = 'enhancement'::character varying)))
>);
>
>But there is no logic to have all those parens plus it makes pg_dump -s
>and \d tablename a whole lot messier to read.
>
>Can anyone clarify why we have it like this? Or whether or not it is a
>bug perhaps? I could understand micro optimizations, but in this case?
>
Obviously psql uses either use pg_constraint.consrc or
pg_get_expr(conbin, conrelid) which both will give this lot of
parentheses, so it's not a bug, but a feature
For easier reengineering, I invented several pg_get_xxx functions with a
pretty-print option, which omits this messy parentheses, because I
noticed how ugly this looks while writing pgAdmin3 (especially for large
views with many joins and big expressions).
There have been suggestions to use the pretty-print options for psql (I
don't know which have been realized so far), and very harsh rejects
doing this in pg_dump, namely from Tom).
Regards,
Andreas