[Fwd: Re: getImportedKeys returns only one key]

Ok,

It looks like the problem has been narrowed down, when I get a few
moments, I will look at what the issues are with column constraints. In
the meantime if tables are defined with foreign key constraints it works
fine.

Dave
-----Forwarded Message-----

From: Ian Wehrman <ian(at)labfire(dot)com>
To: Dave Cramer <Dave(at)micro-automation(dot)net>
Cc: pgsql-jdbc(at)postgresql(dot)org <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: [JDBC] getImportedKeys returns only one key
Date: 02 Jun 2002 15:03:03 -0500

Dave Cramer <Dave(at)micro-automation(dot)net> wrote:
> I tried my test code on a 7.1.3 db and it worked fine, one thin I did
> notice is that I am specifically creating foreign key constraints. I
> don't have time right now to test to see if that makes a difference, but
> if you can; let me know

Dave,
Thanks for your help. I did a bit more testing with this hint, and I think
I've narrowed the problem down further. I can verify that your tests work as
expected, getImportedKeys shows all FOREIGN KEYs that are explicitly created.
The difference, I suspect, is that the FORIEGN KEY attribute is a table
constraint, while the syntax i used created a column constraint. I'm not
entirely sure what the difference is, I only glean this from the psql help for
"create table." So, you're right that table constraints are working fine, but
it does seem that only the last column constraint is showing up in
getImportedKeys(). Try adding the following to your test harness, and I
think you'll see that only one of the constraints show up:

JDBC2Tests.createTable(con1, "users", "id int4 primary key, " +
"people_id int4 references people(id), " +
"policy_id int4 references policy(id)");

I can verify (with "\d tablename") that creating either table or column
constraints properly creates the triggers (of the form
RI_ConstraintTrigger_xxxxx), so it seems like these should be returned by
getImportedKeys(). Thanks for helping me find a workaround though, and let me
know if I can help test any futher.

Thanks,
Ian Wehrman

--
Labfire, Inc.
Seamless Technical Solutions
http://labfire.com/