Thread: Unable To Modify Table
I seem to have an issue where I can't modify a table due to another tables foreign key association: [CODE]trinity=# \d developers Table "public.developers" Column | Type | Modifiers --------------+----------------+-----------id | character(10) | not nullname | character(50) | not nulladdress| character(50) |city | character(50) |state | character(2) |zip | character(10) |country | character(50) |phone | character(50) |email | character(255) | Indexes: "developers_pkey" PRIMARY KEY, btree (id) Referenced by: TABLE "orders" CONSTRAINT "fk_orders_developers" FOREIGN KEY (id) REFERENCES developers(id) [/CODE] Now I want to change the formatting of field data in 'id' in table 'developers': [CODE]trinity=# SELECT id FROM developers; id ------------100000000110000000021000000003100000000410000000051000000006 (109 rows) [/CODE] Now when I try and change the values before I alter the field TYPE, I get an error that another table (orders) with a foreign key associated with public.developers 'id' field still has old values therefor can't change / modify the 'developers' table. [CODE]trinity=# UPDATE developers SET id = '1000' WHERE id = '1000000001'; ERROR: update or delete on table "developers" violates foreign key constraint "fk_orders_developers" on table "orders" DETAIL: Key (id)=(1000000001) is still referenced from table "orders". [/CODE] How does one accomplish my goal? Is this difficult to change or once that foreign key is created, are you stuck with that particular constraint?
On 01/12/2012 08:42 AM, Carlos Mennens wrote: > I seem to have an issue where I can't modify a table due to another > tables foreign key association: > > ... > > How does one accomplish my goal? Is this difficult to change or once > that foreign key is created, are you stuck with that particular > constraint? > Try updating the values in both tables within a transaction with constraints set to deferred: http://www.postgresql.org/docs/current/static/sql-set-constraints.html Cheers, Steve
On Thursday, January 12, 2012 8:42:59 am Carlos Mennens wrote: > I seem to have an issue where I can't modify a table due to another > tables foreign key association: > > [CODE]trinity=# \d developers > Table "public.developers" > Column | Type | Modifiers > --------------+----------------+----------- > id | character(10) | not null > name | character(50) | not null > address | character(50) | > city | character(50) | > state | character(2) | > zip | character(10) | > country | character(50) | > phone | character(50) | > email | character(255) | > Indexes: > "developers_pkey" PRIMARY KEY, btree (id) > Referenced by: > TABLE "orders" CONSTRAINT "fk_orders_developers" FOREIGN KEY (id) > REFERENCES developers(id) > [/CODE] > > > Now when I try and change the values before I alter the field TYPE, I > get an error that another table (orders) with a foreign key associated > with public.developers 'id' field still has old values therefor can't > change / modify the 'developers' table. > > [CODE]trinity=# UPDATE developers SET id = '1000' WHERE id = '1000000001'; > ERROR: update or delete on table "developers" violates foreign key > constraint "fk_orders_developers" on table "orders" > DETAIL: Key (id)=(1000000001) is still referenced from table "orders". > [/CODE] > > How does one accomplish my goal? Is this difficult to change or once > that foreign key is created, are you stuck with that particular > constraint? You are pushing in the wrong direction. You need to make the change in the table 'orders'. This assumes the FK in 'orders' has ON UPDATE CASCADE enabled. -- Adrian Klaver adrian.klaver@gmail.com
-----Original Message----- From: pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org] On Behalf Of Carlos Mennens Sent: Thursday, January 12, 2012 11:43 AM To: PostgreSQL (SQL) Subject: [SQL] Unable To Modify Table I seem to have an issue where I can't modify a table due to another tables foreign key association: [CODE]trinity=# \d developers Table "public.developers" Column | Type | Modifiers --------------+----------------+-----------id | character(10) | not nullname | character(50) | not nulladdress| character(50) |city | character(50) |state | character(2) |zip | character(10) |country | character(50) |phone | character(50) |email | character(255) | Indexes: "developers_pkey" PRIMARY KEY, btree (id) Referenced by: TABLE "orders" CONSTRAINT "fk_orders_developers" FOREIGNKEY (id) REFERENCES developers(id) [/CODE] Now I want to change the formatting of field data in 'id' in table 'developers': [CODE]trinity=# SELECT id FROM developers; id ------------100000000110000000021000000003100000000410000000051000000006 (109 rows) [/CODE] Now when I try and change the values before I alter the field TYPE, I get an error that another table (orders) with a foreign key associated with public.developers 'id' field still has old values therefor can't change / modify the 'developers' table. [CODE]trinity=# UPDATE developers SET id = '1000' WHERE id = '1000000001'; ERROR: update or delete on table "developers" violates foreign key constraint "fk_orders_developers" on table "orders" DETAIL: Key (id)=(1000000001) is still referenced from table "orders". [/CODE] How does one accomplish my goal? Is this difficult to change or once that foreign key is created, are you stuck with that particular constraint? --------------------------------------------------------------- There are two possible actions you can take with respect to an existing Primary Key; you can UPDATE it or you can DELETE it. When you define a FOREIGN KEY you can specify what you want to happen if the corresponding PRIMARY KEY is UPDATEd or DELETEd. Read the documentation on FOREIGN KEY in detail to understand why you are seeing that error and what modifications you can make to the FOREIGN KEY on "orders" to obtain different behavior. Keep in mind, also, that the TYPE of the PRIMARY KEY and FOREIGN KEY must match. Contrary to my earlier advice assigning a sequential ID (thus using a numeric TYPE) is one of the exceptions where you can use a number even though you cannot meaningfully perform arithmetic on the values. The reason you would use a numeric value instead of a character is that the value itself is arbitrary and the space required to store a number is less than the space required to store a string of the same length. There are many points-of-view regarding whether to use "serial" PRIMARY KEYs but regardless of whether you add one or not you should try and define a UNIQUE constraint on the table by using meaningful values. However, for things like Orders this is generally not possible and so you would want to generate a sequential identifier for every record. David J.
-----Original Message----- From: pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org] On Behalf Of Adrian Klaver Sent: Thursday, January 12, 2012 11:55 AM To: pgsql-sql@postgresql.org Cc: Carlos Mennens Subject: Re: [SQL] Unable To Modify Table > > How does one accomplish my goal? Is this difficult to change or once > that foreign key is created, are you stuck with that particular > constraint? You are pushing in the wrong direction. You need to make the change in the table 'orders'. This assumes the FK in 'orders' has ON UPDATE CASCADE enabled. ---------------------------------------- Adrian, you are not helping...if ON UPDATE CASCADE was enabled on "orders" the error in question would never have appeared and the UPDATE would have succeeded. Carlos' goal is to change the value of a Primary Key that has already been used in a FOREIGN KEY constraint and he needs to learn to use the documentation to solve some of these basic questions instead of asking the list. His approach is correct, execute UPDATE against the "developers" table. Deferrable constraints and transactions work as well but are more complicated to setup and execute compared to the more direct ON UPDATE CASCADE modifier to the FOREIGN KEY. But learning both methods is good. David J.
On Thursday, January 12, 2012 9:02:35 am David Johnston wrote: > ---------------------------------------- > > Adrian, you are not helping...if ON UPDATE CASCADE was enabled on "orders" > the error in question would never have appeared and the UPDATE would have > succeeded. Carlos' goal is to change the value of a Primary Key that has > already been used in a FOREIGN KEY constraint and he needs to learn to use > the documentation to solve some of these basic questions instead of asking > the list. His approach is correct, execute UPDATE against the > "developers" table. My mistake, I got the table relationship order wrong. Sorry for the noise. > > David J. -- Adrian Klaver adrian.klaver@gmail.com
On 13/01/12 05:56, David Johnston wrote: <blockquote cite="mid:016a01ccd14b$1f40baf0$5dc230d0$@yahoo.com" type="cite"><prewrap="">[...] Contrary to my earlier advice assigning a sequential ID (thus using a numeric TYPE) is one of the exceptions where you can use a number even though you cannot meaningfully perform arithmetic on the values. The reason you would use a numeric value instead of a character is that the value itself is arbitrary and the space required to store a number is less than the space required to store a string of the same length. There are many points-of-view regarding whether to use "serial" PRIMARY KEYs but regardless of whether you add one or not you should try and define a UNIQUE constraint on the table by using meaningful values. However, for things like Orders this is generally not possible and so you would want to generate a sequential identifier for every record. David J. </pre></blockquote><p class="western" style="margin-bottom: 0cm">Hmm...<br /><br /> In any database I design, I deliberatelykeep primary keys quite separate from any user visible values. In order to minimise changes to the database resultingfrom business format changes, such as redoing the format of customer numbers for marketing purposes. <br /><br />Also, in a chain of parent child tables, the child only needs to know how to get its parent, it does not need to know itsgrandparents! One insurance package I worked on, had the primary key of a child table a concatenation of its parent'sprimary key with a unique field. So some child tables had multiple character field as their primary keys, potentiallyhave keys of some 45 or more characters!<p class="western" style="margin-bottom: 0cm">I normally use integersfor the primary key type. This makes keeping track of records in a program much easier.<p class="western" style="margin-bottom:0cm">However, I do not usually expose these keys to users, and it would be rare (if ever) to have themas fields in search boxes.<br /><br /><br /> Cheers,<br /> Gavin