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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
