Обсуждение: Is cycle references?

The db schema we have need to do a cycle references.  I.e.,
an attribute in table_1 references the key in table_2 and
an attribute in table_2 references the key in table_1.  However,
PostgreSQL does not allow us to make reference to an "non-existing" table!
If we create a fake table_2 first, then create table_1, drop table_2,
create the "real" table_2, we will lost the reference constraint during
droping the "fake" table_2.

Is there any work-around on this issue?

We appreicate your hints.

Limin
pumpkin networks

  I apologize upfront for this message.  I'm under the gun, and things
aren't looking good.

  If anyone has experience using DBI to connect to a PostgreSQL database
that is on a different machine, I could use some help.  One of our packages
(purchased by management...) needs to be migrated ASAP.  I looked in the
code to find where it connects, and changed it to:

DBI->connect("dbi:Pg:dbname=hyperseek;host=10.0.1.100;port=5432")

  It does connect - but does not retrieve any data.  It doesn't seem to be a
permissions issue, the database is owned by the user that is connecting.
Any ideas?

steve

> Be sure to set DBI->trace(2) on.  It helps greatly in tracking errors. I
show it
> below on the database object, but you should be able to set it as a class
> method, I believe. I have done this in the past, but don't see it in any
of my
> code now.

> I realize that this is not exactly what you asked for, but I don't really
> understand what you failure is.  Can you connect via 'psql -h 10.0.1.100
> hyperseek' ?

  Thanks for the letter.  I should have given more detail.

psql -h 10.0.1.100 -d hyperseek -c "\d"

 works just hunky-dorey.  I did a DBI_TRACE, and while I won't pretend to
really understand what's going on, there are no messages indicating errors
or warnings.  (I can provide it if you'd like).  And, there *is* data in the
database.  I checked that very quickly. : )

 the DBI trace shows it connecting as the owner of the table, and shows it
returning the hash when it connects.  When a query is executed, it appears
to function correctly - but no data is returned.  The kicker is that if I
query the tables from PSQL, the data shows up.  Any ideas?  I'm certainly
baffled.

steve

On Wed, 1 Nov 2000 limin@www.pumpkinnet.com wrote:

>
> The db schema we have need to do a cycle references.  I.e.,
> an attribute in table_1 references the key in table_2 and
> an attribute in table_2 references the key in table_1.  However,
> PostgreSQL does not allow us to make reference to an "non-existing" table!
> If we create a fake table_2 first, then create table_1, drop table_2,
> create the "real" table_2, we will lost the reference constraint during
> droping the "fake" table_2.
>
> Is there any work-around on this issue?
Use ALTER TABLE ADD CONSTRAINT to add the constraint after
the second table is made.

On Wed, 1 Nov 2000 limin@www.pumpkinnet.com wrote:

> The db schema we have need to do a cycle references.  I.e.,
> an attribute in table_1 references the key in table_2 and
> an attribute in table_2 references the key in table_1.  However,
> PostgreSQL does not allow us to make reference to an "non-existing" table!
>
> Is there any work-around on this issue?

I had the same problem.  You can play around with creating the tables
without the RI checks and adding the constraints later, but I found this
clumsy.

The solution I used was to have a third table with attributes referencing
keys from table_1 and table_2.  This avoids the problem of inserting
references to keys which don't exist yet, and you can use joins from
table_[12] to table_3 to do the same queries you would have done with the
cross-referential tables.
--
Tod McQuillin

Tod McQuillin wrote:
> On Wed, 1 Nov 2000 limin@www.pumpkinnet.com wrote:
>
> > The db schema we have need to do a cycle references.  I.e.,
> > an attribute in table_1 references the key in table_2 and
> > an attribute in table_2 references the key in table_1.  However,
> > PostgreSQL does not allow us to make reference to an "non-existing" table!
> >
> > Is there any work-around on this issue?
>
> I had the same problem.  You can play around with creating the tables
> without the RI checks and adding the constraints later, but I found this
> clumsy.
>
> The solution I used was to have a third table with attributes referencing
> keys from table_1 and table_2.  This avoids the problem of inserting
> references to keys which don't exist yet, and you can use joins from
> table_[12] to table_3 to do the same queries you would have done with the
> cross-referential tables.

    One of the reasons to setup referential integrity constraints
    is to avoid inserting references to keys that don't exist, so
    getting  around it with your 3-table setup looks a little odd
    to me.

    You'd better think about declaring your constraints INITIALLY
    DEFERRED  and  cover  the  key-  and  reference-insertions by
    proper transaction blocks.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #