From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | bug in information_schema? |
Date: | 2004-11-27 14:24:40 |
Message-ID: | slrncqh3h8.2kf6.andrew+nonews@trinity.supernews.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Found this in 7.4.5, verified it's still in 8.0b4:
test=> select * from information_schema.referential_constraints;
test|public|$1|test|public|reftest1_pkey|NONE|NO ACTION|CASCADE
test|public|$1|test|public|reftest1_pkey|NONE|NO ACTION|NO ACTION
test|public|$1|test|public|reftest1_pkey|NONE|NO ACTION|NO ACTION
In that case there are three tables all referencing the same column of a
fourth - but there is no way at all to tell which row corresponds to which
table, and hence no way to join against, say, table_constraints.
A similar issue may exist with the check_constraints view, which was the
only other place I found where constraint_name is used without any table
name being present. I don't know what the spec says, but it seems that
something is assuming that constraint_name is unique within the schema,
which of course is not the case in the above example.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
From | Date | Subject | |
---|---|---|---|
Next Message | Troels Arvin | 2004-11-27 15:19:31 | Re: bug in information_schema? |
Previous Message | Neil Conway | 2004-11-27 13:56:31 | plpgsql unreachable code (was BUG #1329: Bug in IF-ELSEIF-ELSE construct) |