From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | "Panon, Paul-Andre" <Paul-AndrePanon(at)SierraSystems(dot)com> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ADD CONSTRAINT ... FOREIGN KEY and custom data type. |
Date: | 2001-02-06 17:08:37 |
Message-ID: | Pine.BSF.4.21.0102060903580.43759-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I think you may be running into the now fixed (for 7.1) bug where
ADD CONSTRAINT ... FOREIGN KEY got the column ordering wrong when checking
existing data. I may be able to build a patch against 7.0.x since the
fix is relatively minor if you don't plan to upgrade when 7.1 comes out.
On Mon, 5 Feb 2001, Panon, Paul-Andre wrote:
>
> For a project we are working on, I have created a custom postgresql data
> type which is similar to MS SQL Server's uniqueidentifier data type. It uses
> dynamic link library extension that calls the FreeDCE library to generate
> GUIDs. Support for the data type and support functions is added to a
> PostgreSQL database using the attached SQL script. The functions all seems
> to work fine, including use of merge sorts and hash joins during SQL JOIN
> statements when using the data type as part of a primary key. However
> adding foreign key constraints sometimes causes a problem.
>
> I never have a problem adding a foreign key to a parent table with a
> multi-part key as long as the child table is empty. Adding data to the child
> entity afterwards seems to properly enforce RI. However, if data exists in
> the child entity, an RI check is performed on the existing data and this
> check sometimes seems to break. As far as I can tell, the RI check in the
> latter case seems to confuse the order the Key parts in either the Primary
> Key or the Foreign Key. In the case of a multi-part key RI, it was
> complaining that it couldn't perform a type conversion between the type of
> two different key parts of the primary key.
>
> So in a database with the following table definitions (OK I know it isn't
> exactly great DB design to have 4 uniqueidentifiers in a PK, but please bear
> with me) :
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2001-02-06 17:16:26 | Re: little bug in current CVS |
Previous Message | Peter Eisentraut | 2001-02-06 16:43:16 | Re: [HACKERS] Re: syslog logging setup broken? |