Weird constraint output

From: Jeroen Ruigrok/asmodai <asmodai(at)wxs(dot)nl>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Weird constraint output
Date: 2003-08-28 06:23:51
Message-ID: 20030828062351.GH42098@nexus.ninth-circle.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[Please hold me on the to:/cc: list since I am not subscribed]

After talking this over with some of the great guys on IRC it was
suggested I ask here.

I am currently working on a document about how to convert from MySQL to
PostgreSQL (Sybase, Oracle, DB2, MS SQL Server are also going to be
done). I am now messing with CONSTRAINT CHECK and am encountering
something I don't see the logic of.

I decided to make sure Bugzilla works on pgsql 7.3.x and started to
convert the MySQL database schema to a pgsql one. One of the parts has
a layout like:

CREATE TABLE bugs (
-- ...skipping to relevant point
bug_severity character varying(50) -- in MySQL this is enum()
);

Next I did an:

ALTER TABLE ONLY bugs ADD CONSTRAINT bugs_severity_cstr CHECK
(bug_severity IN ('blocker', 'critical', 'major'));

Now, when I do a \d bugs I get:

Check constraints: "bugs_severity_cstr" (((bug_severity =
'blocker'::character varying) OR (bug_severity = 'critical'::character
varying)) OR (bug_severity = 'major'::character varying))

I would've expected:

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?

Thanks,

--
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
One moon shows in every pool; in every pool, the one moon...

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomka Gergely 2003-08-28 06:38:47 Re: Hardware recommendations to scale to silly load
Previous Message Joe Conway 2003-08-28 05:46:58 Re: [HACKERS] 2-phase commit