unfortunately...

This is simplest case. Keeping in mind triggers
I would like to see Oracle behaviour some day and so
I decided to do not implement FOREIGN keys in 6.4 -:((
Sorry.

No problem. We have a nice feature set for v6.4 anyway, and it leaves at
least one thing to do for v6.5 :)

- Tom

On Fri, 25 Sep 1998, Vadim Mikheev wrote:

I don't like implementation of referential integrity constraints
in contrib/spi/refint.* and implementation of ... unique indices:
backend checks constraints when tuple is changed.

Oracle checks constraints after entire _statement_ is done.
Do you remember this:

vac=> create table x (a int unique);
NOTICE: CREATE TABLE/UNIQUE will create implicit index x_a_key for table x
CREATE
vac=> insert into x values (1);
INSERT 143852 1
vac=> insert into x values (2);
INSERT 143853 1
vac=> update x set a = a + 1;
ERROR: Cannot insert a duplicate key into a unique index

This is simplest case. Keeping in mind triggers
I would like to see Oracle behaviour some day and so
I decided to do not implement FOREIGN keys in 6.4 -:((

Sounds reasonable to me...all things considered, I think that v6.4
has turned out, once more, to be one giant leap forward :)

Sorry.

Don't be...I think if Bruce had his way, we'd be funding a cloning
project just so that we could get a dozen of you :) Its nice to be
reminded once in a while that you are "only human" *grin*

I don't like implementation of referential integrity constraints
in contrib/spi/refint.* and implementation of ... unique indices:
backend checks constraints when tuple is changed.

Oracle checks constraints after entire _statement_ is done.
Do you remember this:

vac=> create table x (a int unique);
NOTICE: CREATE TABLE/UNIQUE will create implicit index x_a_key for table x
CREATE
vac=> insert into x values (1);
INSERT 143852 1
vac=> insert into x values (2);
INSERT 143853 1
vac=> update x set a = a + 1;
ERROR: Cannot insert a duplicate key into a unique index

This is simplest case. Keeping in mind triggers
I would like to see Oracle behaviour some day and so
I decided to do not implement FOREIGN keys in 6.4 -:((

OK. Removed from open 6.4 items list.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thus spake Vadim Mikheev

I decided to do not implement FOREIGN keys in 6.4 -:((

Does this mean that we also won't have full primary key support? It
seems to me like it could be implemented without worrying about foreign
keys but you know better. I can work around it given the support
already there but it would be nice if making a field primary would
automatically set the relevant indisprimary field right now.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.