Thread: unfortunately...
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 -:(( Sorry. Vadim
> 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.