Postgres Pro
Downloads
Home   >   mailing lists

Thread: on update restrict

on update restrict

From
"Mister ics"
Date:
Hi,

I'm a little confused by the "on update restrict" option in a referential 
integrity constraint. I don't know if i have not understood the meaning of 
this statement or it does not work properly.
I think that if it is specified ON UPDATE RESTRICT in a foreign key 
costraint, the sql-server should not perform updates on the referenced rows. 
Here an example:

testdb=>create table t1 (id int primary key,foo int);
NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 't1_pkey' for 
table 't1'
CREATE

testdb=>create table t2 (id int primary key,ref int references t1(id) on update restrict);
NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 't2_pkey' for 
table 't2'
NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY 
check(s)
CREATE

testdb=>insert into t1 values (1,3000);
INSERT 19116 1
testdb=>insert into t2 values (1,1);
INSERT 19117 1

testdb=> update t1 set foo=2900 where id=1;
UPDATE 1    <--- for me is wrong, we have updated a row referenced by t2 
with ON UPDATE RESTRICT OPTION

What do you think about ?

Thanks in advance

Regards, Silvio



_________________________________________________________________
Scarica GRATUITAMENTE MSN Explorer all'indirizzo 
http://explorer.msn.it/intl.asp

Re: on update restrict

From
Jan Wieck
Date:
Mister ics wrote:
> Hi,
>
> I'm a little confused by the "on update restrict" option in a referential
> integrity constraint. I don't know if i have not understood the meaning of
> this statement or it does not work properly.
> I think that if it is specified ON UPDATE RESTRICT in a foreign key
> costraint, the sql-server should not perform updates on the referenced rows.
> Here an example:
>
> testdb=>create table t1 (
>    id int primary key,
>    foo int);
> NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 't1_pkey' for
> table 't1'
> CREATE
>
> testdb=>create table t2 (
>    id int primary key,
>    ref int references t1(id) on update restrict);
> NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 't2_pkey' for
> table 't2'
> NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
> check(s)
> CREATE
>
> testdb=>insert into t1 values (1,3000);
> INSERT 19116 1
> testdb=>insert into t2 values (1,1);
> INSERT 19117 1
>
> testdb=> update t1 set foo=2900 where id=1;
> UPDATE 1    <--- for me is wrong, we have updated a row referenced by t2
> with ON UPDATE RESTRICT OPTION
>
> What do you think about ?
   The behaviour is correct according to the SQL specifications.   RESTRICT (as well as NO ACTION) means, you cannot
change the   primary key value of the referenced row. All other values can   be changed of course.
 
   So an attempt to
       UPDATE t1 SET id = 2 WHERE id = 1;
   is the thing prevented in your above example.


Jan

--

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



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: on update restrict

From
Alan Gutierrez
Date:
On Tue, 14 Aug 2001, Jan Wieck wrote:

> Mister ics wrote:
> > testdb=>create table t1 (
> >    id int primary key,
> >    foo int);

> > testdb=>create table t2 (
> >    id int primary key,
> >    ref int references t1(id) on update restrict);

>     So an attempt to
>
>         UPDATE t1 SET id = 2 WHERE id = 1;
>
>     is the thing prevented in your above example.

I find it odd that you specify a restiction on one table in the definition of
another table.

Sorry, if this was a double post.

Alan Gutierrez

Re: on update restrict

From
"Mister ics"
Date:
>
>     The behaviour is correct according to the SQL specifications.
>     RESTRICT (as well as NO ACTION) means, you cannot change  the
>     primary key value of the referenced row. All other values can
>     be changed of course.
>
>     So an attempt to
>
>         UPDATE t1 SET id = 2 WHERE id = 1;
>
>     is the thing prevented in your above example.
>
>
>Jan
>


Hi Jan,

Thank you , i  understand now.

Do you know a method to block the update of certain rows in a table not 
using the triggers ? I explain better:
I have the needing to prevent the updating of a set of rows in a table. The 
first solution i can find is to use a boolean column (es. "Blocked") and 
rising a trigger on updating the table. The trigger checks if the row is 
updatable or not (checking the "Blocked" column).
Is this the only (or better) way to do this ?

Thanks,

Silvio

_________________________________________________________________
Scarica GRATUITAMENTE MSN Explorer all'indirizzo 
http://explorer.msn.it/intl.asp

Re: on update restrict

From
Jan Wieck
Date:
Mister ics wrote:
> >
> >     The behaviour is correct according to the SQL specifications.
> >     RESTRICT (as well as NO ACTION) means, you cannot change  the
> >     primary key value of the referenced row. All other values can
> >     be changed of course.
> >
> >     So an attempt to
> >
> >         UPDATE t1 SET id = 2 WHERE id = 1;
> >
> >     is the thing prevented in your above example.
> >
> >
> >Jan
> >
>
>
> Hi Jan,
>
> Thank you , i  understand now.
>
> Do you know a method to block the update of certain rows in a table not
> using the triggers ? I explain better:
> I have the needing to prevent the updating of a set of rows in a table. The
> first solution i can find is to use a boolean column (es. "Blocked") and
> rising a trigger on updating the table. The trigger checks if the row is
> updatable or not (checking the "Blocked" column).
> Is this the only (or better) way to do this ?
   Since  you  only want to suppress the operation in that case,   it could be done with a rule too. But  I  think  the
cleaner   solution  is  with  a  BEFORE  trigger  raising  an  ERROR or   returning NULL to suppress the operation.
 
   And consider that you might want to be able  to  unblock  the   row's  again.   In  that  case, the trigger is the
onlyway I   see, because you need  the  procedural  logic  to  check  the   blocked true->false transition and let THAT
changehappen.
 


Jan

--

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



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com