I don't think I understand what VALIDATE CONSTRAINT is supposed to do. I am converting a database for use in the upcoming major upgrade of my company's flagship software product. Past developers were lazy, and didn't bother specifying foreign keys where they should have. For the new version of our product, appropriate foreign keys will be specified and enforced.
So, I want to import data into my new database and then make sure there are no foreign key violations. After wrestling with when transactions begin and end and dealing with circular keys and getting nowhere at amazing speed, I decided merely disable all triggers on all tables (which disables foreign key constraint checking in PostgreSQL, since they use triggers under the hood), import my data, re-enable the triggers, and then issue a VALIDATE CONSTRAINT command. However, in my little test script, the validation fails to find any constraint violations. Why not?
Here's the test script. I am creating a table named gas_types_minimum with a column named gas_type. I am not creating any records in that table. Then, I create a table named base_types_minimum with a column named base_type and a column named gas_type. I disable its triggers so I can insert a base_type record even though there is no gas_type record. Then, I insert a Hydrogen base type with a gas type of 'H2'. Then, I turn triggers back on and validate the constraint. I get no error.
DROP TABLE IF EXISTS base_types_minimum;
DROP TABLE IF EXISTS gas_types_minimum;
CREATE TABLE public.gas_types_minimum
(
gas_type character varying(32) COLLATE pg_catalog."default",
CONSTRAINT gas_type_minimum_pkey PRIMARY KEY (gas_type)
);
CREATE TABLE public.base_types_minimum
(
base_type character varying(32) COLLATE pg_catalog."default" NOT NULL,
gas_type character varying(32) COLLATE pg_catalog."default",
CONSTRAINT base_type_minimum_pkey PRIMARY KEY (base_type),
CONSTRAINT base_type_minimum_gas_type_minimum_fk FOREIGN KEY (gas_type)
REFERENCES public.gas_types_minimum (gas_type) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
);
alter table base_types_minimum disable trigger all;
insert into base_types_minimum values ('Hydrogen', 'H2');
alter table base_types_minimum enable trigger all;
alter table base_types_minimum validate constraint base_type_minimum_gas_type_minimum_fk;
The reason is that the foreign key constraint is already marked as valid, so it is not checked.
VALIDATE CONSTRAINT is only useful for constraints that were defined as NOT VALID, which your constraint was not. There is no supported way to invalidate a constraint later on, because it is not considered useful.
By disabling the triggers you effectively broke integrity, and there is no way to recover. That is why you can only disable a trigger that implements a foreign key if you are a superuser (these are expected to know what they are doing).
The best thing for you to do is to drop the broken foreign key constraint.
There is one – unsupported! – way how you can mark the constraint invalid:
UPDATE pg_catalog.pg_constraint
SET convalidated = FALSE
WHERE conname = 'base_type_minimum_gas_type_minimum_fk';
You can only do that as superuser, and I don't recommend it. Just drop that foreign key constraint.
Related
I have a table named base_types that contains this constraint:
ALTER TABLE public.base_types
ADD CONSTRAINT base_type_gas_type_fk FOREIGN KEY (gas_type)
REFERENCES public.gas_types (gas_type) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED;
And I have a table named alarm_history that contains five constraints, including this one:
ALTER TABLE public.alarm_history
ADD CONSTRAINT alarm_history_device_fk FOREIGN KEY (device)
REFERENCES public.bases (alarm_device) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED;
I am trying to convert a database from one that didn't bother with anything weird and useless like constraints into one that uses them. I am beginning with this script:
delete from gas_types;
select conversion.convert_base_types();
alter table base_types validate constraint base_type_gas_type_fk;
select conversion.convert_alarm_history();
alter table alarm_history validate constraint alarm_history_base_fk;
alter table alarm_history validate constraint alarm_history_charge_fk;
alter table alarm_history validate constraint alarm_history_cooler_fk;
alter table alarm_history validate constraint alarm_history_device_fk;
alter table alarm_history validate constraint alarm_history_furnace_fk;
I duly get an error message telling me that the gas_type field in my new base_types record doesn't match anything in the gas_types table, since the gas_types table is empty. But if I comment out the base_types commands, I get 18,000 nice, shiny new records in the alarm_history table, despite the fact that every single one of them violates at least one of that table's five foreign key constraints, since all of the tables those keys are referring to are empty. I need to ensure that my converted data is consistent, and therefore I need to validate my constraints, but that's obviously not happening. Why not?
Since the constraints above are created as DEFERRABLE INITIALLY DEFERRED, they are not checked until the DML statements (your delete statement) are committed or in your case you until you explicitly validate the constraint.
This is the normal and expected operation of an initially deferred deferrable constraint.
To change this functionality within your current transaction you can issue a SET CONSTRAINTS command to alter this:
SET CONSTRAINTS alarm_history_device_fk IMMEDIATE;
delete from gas_types;
Which should raise a foreign key violation alerting you earlier that you have data dependent on the records you are tying to delete.
In order to delete some rows referenced by a foreign key constraint without cascading on delete, I created a temporary foreign key constraint, deleted the row, and then deleted the temporary constraint:
ALTER TABLE rel_user_right
ADD CONSTRAINT temp_fk_rel_user_right_user_right_02
FOREIGN KEY (right_id) REFERENCES user_right (id)
ON DELETE CASCADE;
DELETE FROM user_right WHERE "name" LIKE '%.statusLight.%';
ALTER TABLE rel_user_right
DROP CONSTRAINT temp_fk_rel_user_right_user_right_02;
where this table already had the following constraint defined on it:
ALTER TABLE rel_user_right
ADD CONSTRAINT fk_rel_user_right_user_right_02
FOREIGN KEY (right_id) REFERENCES user_right (id);
This worked fine for me, but seems to have failed on my colleague's computer. As you can see, the two FK constraints define conflicting ON DELETE behaviour. Is precedence defined in this situation, or is it non-deterministic?
Postgres allows to create two references differing only in ON DELETE clause.
I could find no information on the impact of such a case.
In my tests I was unable to cover the existing constraint with new one (i.e. DELETE was always restricted despite of the existence of the second cascading constraint).
However this behaviour is undocumented and one should not rely on it.
The normal way to proceed should be replacing the old constraint with new one:
ALTER TABLE rel_user_right
ADD CONSTRAINT fk_rel_user_right_user_right_temp
FOREIGN KEY (right_id) REFERENCES user_right (id)
ON DELETE CASCADE,
DROP CONSTRAINT fk_rel_user_right_user_right;
DELETE FROM user_right WHERE "name" LIKE '%.statusLight.%';
ALTER TABLE rel_user_right
ADD CONSTRAINT fk_rel_user_right_user_right
FOREIGN KEY (right_id) REFERENCES user_right (id),
DROP CONSTRAINT fk_rel_user_right_user_right_temp;
DISABLE CONSTRAINT would be useful here, but there is no such feature in Postgres (there have been attempts to implement it, but they did not end in success). You can use DISABLE TRIGGER for it, but the above solution is simpler and more natural.
I have the following tables:
CREATE TABLE mail (
id serial,
parent_mail_id integer,
...
PRIMARY KEY (id),
FOREIGN KEY (parent_mail_id) REFERENCES mail(id),
...
);
CREATE TABLE incoming (
from_contact_id integer NOT NULL REFERENCES contact(id),
...
PRIMARY KEY (id),
---> FOREIGN KEY (parent_mail_id) REFERENCES mail(id), <---
...
) INHERITS(mail);
CREATE TABLE outgoing (
from_user_id integer NOT NULL REFERENCES "user"(id),
...
PRIMARY KEY (id),
--> FOREIGN KEY (parent_mail_id) REFERENCES mail(id), <--
...
) INHERITS(mail);
incoming and outgoing inherit from mail and define their foreign keys (and primary keys) again, as they are not automatically inherited.
The problem is:
If I'd insert an incoming mail, it is not possible to reference it from the outgoing table as the foreign key only works with the super table (mails).
Is there a workaround for that?
PostgreSQL 9.3 docs:
A serious limitation of the inheritance feature is that indexes
(including unique constraints) and foreign key constraints only apply
to single tables, not to their inheritance children. This is true on
both the referencing and referenced sides of a foreign key constraint.
Thus, in the terms of the above example:
If we declared cities.name to be UNIQUE or a PRIMARY KEY, this would not stop the capitals table from having rows with names
duplicating rows in cities. And those duplicate rows would by default
show up in queries from cities. In fact, by default capitals would
have no unique constraint at all, and so could contain multiple rows
with the same name. You could add a unique constraint to capitals, but
this would not prevent duplication compared to cities.
Similarly, if we were to specify that cities.name REFERENCES some other table, this constraint would not automatically propagate to
capitals. In this case you could work around it by manually adding the
same REFERENCES constraint to capitals.
Specifying that another table's column REFERENCES cities(name) would allow the other table to contain city names, but not capital
names. There is no good workaround for this case.
These deficiencies will probably be fixed in some future release, but
in the meantime considerable care is needed in deciding whether
inheritance is useful for your application.
And not really a workaround, so maybe make mails a non-inherited table, and then separate incoming_columns and outgoing_columns for their respective extra columns, with the mail id as both their primary and foreign key. You can then create a view outgoing as mail INNER JOIN outgoing_columns, for example.
You may use a constraint trigger
CREATE OR REPLACE FUNCTION mail_ref_trigger()
RETURNS trigger AS
$BODY$
DECLARE
BEGIN
IF NOT EXISTS (
SELECT 1 FROM mail WHERE id = NEW.parent_mail_id
) THEN
RAISE foreign_key_violation USING MESSAGE = FORMAT('Referenced mail id not found, mail_id:%s', NEW.parent_mail_id);
END IF;
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
CREATE CONSTRAINT TRIGGER mail_fkey_trigger
AFTER UPDATE OR INSERT ON incoming
DEFERRABLE
FOR EACH ROW EXECUTE PROCEDURE mail_ref_trigger();
If I script a table with a foreign key, it looks like this:
GO
ALTER TABLE [dbo].[MyTable] WITH CHECK ADD CONSTRAINT [FK_MyTable_SomeCol] FOREIGN KEY([SomeCol])
REFERENCES [dbo].[MyOtherTable] ([SomeCol])
GO
ALTER TABLE [dbo].[MyTable] CHECK CONSTRAINT [FK_MyTable_SomeCol]
GO
What is the second part for (ALTER TABLE [dbo].[MyTable] CHECK CONSTRAINT [FK_MyTable_SomeCol])?
It's an artifact of the way that the constraint is scripted - although it's unnecessary to specify these options (since they're the defaults for new constraints), the same generator can also generate NOCHECK options in exactly the same manner.
Documentation for ALTER TABLE indicates two distinct uses of CHECK/NOCHECK:
WITH CHECK | WITH NOCHECK
Specifies whether the data in the table is or is not validated against a newly added or re-enabled FOREIGN KEY or CHECK constraint. If not specified, WITH CHECK is assumed for new constraints, and WITH NOCHECK is assumed for re-enabled constraints.
And:
{ CHECK | NOCHECK } CONSTRAINT
Specifies that constraint_name is enabled or disabled.
So one option is saying "check the current contents of the table", the other is saying "Validate new data as it is added".
This is a way of implementing referential integrity for your tables.
I have created a database in PostgreSQL (8.4 - I need to use this version because I want to use MapFish which does not (yet) support 9.0) which has some inherited tables:
CREATE TABLE stakeholder
(
pk_stakeholder integer DEFAULT nextval('stakeholder_seq') NOT NULL,
fk_stakeholder_type integer NOT NULL,
name character varying(255) NOT NULL,
CONSTRAINT stakeholder_primarykey PRIMARY KEY (pk_stakeholder),
CONSTRAINT stakeholder_fk_stakeholder_type FOREIGN KEY (fk_stakeholder_type)
REFERENCES stakeholder_type (pk_stakeholder_type) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE NO ACTION
);
CREATE TABLE individual
(
firstname character varying(50),
fk_title integer,
email1 character varying (100),
email2 character varying (100),
phone1 character varying (50),
phone2 character varying (50),
CONSTRAINT individual_primarykey PRIMARY KEY (pk_stakeholder),
CONSTRAINT individual_fk_title FOREIGN KEY (fk_title)
REFERENCES individual_title (pk_individual_title) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE NO ACTION
) INHERITS (stakeholder)
(as learned from an earlier question, I'm using a seperate table (stakeholder_pk) to keep track of my primary keys using triggers)
Now I'd like to reflect my database in SQLAlchemy (0.7.1):
meta.metadata.reflect(bind=engine)
table_stakeholder = meta.metadata.tables["stakeholder"]
table_individual = meta.metadata.tables["individual"]
stakeholder_mapper = orm.mapper(Stakeholder, table_stakeholder,
polymorphic_on=table_stakeholder.c.fk_stakeholder_type,
polymorphic_identity='stakeholder')
orm.mapper(Individual, table_individual, inherits=stakeholder_mapper,
polymorphic_identity='individual')
This however results in an sqlalchemy.exc.ArgumentError: Can't find any foreign key relationships between 'stakeholder' and 'individual'.
Now I've seen some examples where they use the primary key of the child tables (in my case: individual) as a foreign key to point at the primary key of the parent table (stakeholder). However, PostgreSQL will not let me do this, saying that this would violate a foreign key constraint since the primary key in the parent table (stakeholder) is not there (?).
So now I'm pretty much stuck and after hours of searching for a solution I'm starting to lose track of it. Is this a problem in PostgreSQL (similar to the primary key & inheritance issue) or is it because of SQLAlchemy? Or is it just me doing something fundamentally wrong?
It is in PostgreSQL:
All check constraints and not-null constraints on a parent table are automatically inherited by its children. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited.
These deficiencies will probably be fixed in some future release, but in the meantime considerable care is needed in deciding whether inheritance is useful for your application.
http://www.postgresql.org/docs/9.0/interactive/ddl-inherit.html
Is it possible to drop triggers and to have in individual:
pk_stakeholder integer DEFAULT nextval('stakeholder_seq') NOT NULL,
...
CONSTRAINT stakeholder_primarykey PRIMARY KEY (pk_stakeholder),
This will not stop individual to have pk_stakeholder that exists in stakeholder if you update pk_stakeholder later. So here triggers are required to stop update (easier) or to check.