Weird constraint output

Поиск
Список
Период
Сортировка
От Jeroen Ruigrok/asmodai
Тема Weird constraint output
Дата
Msg-id 20030828062351.GH42098@nexus.ninth-circle.org
обсуждение исходный текст
Ответы Re: Weird constraint output  (Andreas Pflug <pgadmin@pse-consulting.de>)
Список 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...


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Kräutner
Дата:
Сообщение: Re: Possible bug in update?
Следующее
От: David Schultz
Дата:
Сообщение: memory allocation and powers of two