Thread: DatabaseMetaData.get(Imi|Ex)portedKeys() and FK_NAME column
Hello,
when I call getExportedKeys() or getImportedKeys() on DatabaseMetaData
object returned by getMetaData() called on Connection object, I receive
ResultSet with standard (defined in JDBC) columns. One of it is FK_NAME
and it gives the name of FOREIGN KEY CONSTRAINT. So if I define some
foreign key eg. like this:
<sql>
...
CONSTRAINT "worker.role.fk"
FOREIGN KEY ("id_worker")
REFERENCES "persons" ("id_person")
ON DELETE CASCADE
ON UPDATE CASCADE
...
</sql>
I expect to get "worker.role.fk" in FK_NAME column. At least I get
what I suppose I shall get when it concerns PRIMARY KEY (PK_NAME).
But in case of FK_NAME I get something like this:
worker.role.fk\000stands\000persons\000UNSPECIFIED\000id_worker\000id_person\000
(this is one, long string). Is this correct? I mean shall all these
\000 escape codes and other identifiers appear in FK_NAME? I thought
that only the part from begining to the first occurence of '\', excluding it, should be returned. Am I right, ergo there we have some
bug or this string is properly composed and I need do substring() on
it to get the FK_NAME?
I use PSQL 7.3.4 on cygwin, j2sdk1.4.2 and recent pg73jdbc3.jar (build
#113).
TIA.
PS.
I have forgotten the email address under which I have subscribed to
this list. I was hoping to get users list from majordomo, but it
doesn't give out that kind of information. How may I find out under
what address I am subscribed and/or how to change that old address
to the new one? If this needs manual work of the masters of the list,
I can provide possible addresses I probably used while subscribing.
Best regards,
Attachment
I beleive this is fixed in the latest development version. Can you download the 7.4 driver from jdbc.postgresql.org to verify that the latest version of the driver fixes this problem. thanks, --Barry Tomisław Kityński wrote: > Hello, > > when I call getExportedKeys() or getImportedKeys() on DatabaseMetaData > object returned by getMetaData() called on Connection object, I receive > ResultSet with standard (defined in JDBC) columns. One of it is FK_NAME > and it gives the name of FOREIGN KEY CONSTRAINT. So if I define some > foreign key eg. like this: > > <sql> > ... > CONSTRAINT "worker.role.fk" > FOREIGN KEY ("id_worker") > REFERENCES "persons" ("id_person") > ON DELETE CASCADE > ON UPDATE CASCADE > ... > </sql> > > I expect to get "worker.role.fk" in FK_NAME column. At least I get > what I suppose I shall get when it concerns PRIMARY KEY (PK_NAME). > But in case of FK_NAME I get something like this: > > worker.role.fk\000stands\000persons\000UNSPECIFIED\000id_worker\000id_person\000 > > (this is one, long string). Is this correct? I mean shall all these > \000 escape codes and other identifiers appear in FK_NAME? I thought > that only the part from begining to the first occurence of '\', excluding it, should be returned. Am I right, ergo therewe have some > bug or this string is properly composed and I need do substring() on > it to get the FK_NAME? > > I use PSQL 7.3.4 on cygwin, j2sdk1.4.2 and recent pg73jdbc3.jar (build > #113). > > TIA. > > PS. > I have forgotten the email address under which I have subscribed to > this list. I was hoping to get users list from majordomo, but it > doesn't give out that kind of information. How may I find out under > what address I am subscribed and/or how to change that old address > to the new one? If this needs manual work of the masters of the list, > I can provide possible addresses I probably used while subscribing. > > Best regards, >
Tomistaw, this is the correct return value. The problem is you can create an unnamed foreign key as in create table worker1 ( id serial, id_worker int, FOREIGN KEY (id_worker) references person(id) on delete cascade on update cascade); At least it used to be unnamed, it now appears to be named "$1" so we returned the whole string. It appears that this can now be changed. Dave On Tue, 2003-08-26 at 14:46, Tomisław Kityński wrote: > Hello, > > when I call getExportedKeys() or getImportedKeys() on DatabaseMetaData > object returned by getMetaData() called on Connection object, I > receive > ResultSet with standard (defined in JDBC) columns. One of it is > FK_NAME > and it gives the name of FOREIGN KEY CONSTRAINT. So if I define some > foreign key eg. like this: > > <sql> > ... > CONSTRAINT "worker.role.fk" > FOREIGN KEY ("id_worker") > REFERENCES "persons" ("id_person") > ON DELETE CASCADE > ON UPDATE CASCADE > ... > </sql> > > I expect to get "worker.role.fk" in FK_NAME column. At least I get > what I suppose I shall get when it concerns PRIMARY KEY (PK_NAME). > But in case of FK_NAME I get something like this: > > worker.role.fk\000stands\000persons\000UNSPECIFIED\000id_worker\000id_person\000 > > (this is one, long string). Is this correct? I mean shall all these > \000 escape codes and other identifiers appear in FK_NAME? I thought > that only the part from begining to the first occurence of '\', > excluding it, should be returned. Am I right, ergo there we have some > bug or this string is properly composed and I need do substring() on > it to get the FK_NAME? > > I use PSQL 7.3.4 on cygwin, j2sdk1.4.2 and recent pg73jdbc3.jar (build > #113). > > TIA. > > PS. > I have forgotten the email address under which I have subscribed to > this list. I was hoping to get users list from majordomo, but it > doesn't give out that kind of information. How may I find out under > what address I am subscribed and/or how to change that old address > to the new one? If this needs manual work of the masters of the list, > I can provide possible addresses I probably used while subscribing. > > Best regards, > [image] -- Dave Cramer <Dave@micro-automation.net>
----- Original Message ----- From: "Barry Lind" <blind@xythos.com> To: "Tomisław Kityński" <t.kitynski@11interactive.com> Cc: <pgsql-jdbc@postgresql.org> Sent: Wednesday, August 27, 2003 9:40 PM Subject: Re: [JDBC] DatabaseMetaData.get(Imi|Ex)portedKeys() and FK_NAME column > I beleive this is fixed in the latest development version. Can > you download the 7.4 driver from jdbc.postgresql.org to verify > that the latest version of the driver fixes this problem. Indeed, it does 8) Thx! 8)