What is the query to disable all constraints like foreign keys, primary keys but leave uniques?
PostgreSQL does not allow to disable constraints generally speaking. You can only disable foreign key constraints by disabling the related trigger used to implement the foreign keys.
See https://www.postgresql.org/docs/12/sql-altertable.html#SQL-ALTERTABLE-NOTES
DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER
One can disable or enable a single trigger specified by name, or all
triggers on the table, or only user triggers (this option excludes
internally generated constraint triggers such as those that are used
to implement foreign key constraints or deferrable uniqueness and
exclusion constraints). Disabling or enabling internally generated
constraint triggers requires superuser privileges; it should be done
with caution since of course the integrity of the constraint cannot be
guaranteed if the triggers are not executed.
Related
I'd like just to confirm if the 'ALTER TABLE table_name DISABLE TRIGGER ALL' also disables DOMAIN checks in Postgres?
No, DOMAIN and CHECK constraints are not disabled.
Only some constraints are implemented as triggers in Postgres. The most notable would be a trigger on the "parent" table in the FK constraint, and triggers on deferrable unique / exclusion constraints. These require some complicated logic that cannot be checked against a single row and were, consequently, implemented as triggers.
DOMAIN checks are entirely "internal", the checks cannot use subqueries, and by all means operate like CHECK constraints. There should be no triggers.
You could check pg_trigger to see if your target table has any "internally defined' triggers.
It seems like when I
ALTER TABLE foo DISABLE TRIGGER ALL;
DELETE FROM foo;
The deletions don't get cascaded to other tables with
FOREIGN KEY ("fooId") REFERENCES "foo"("id") ON DELETE CASCADE
constraints, but I can't find anything in the documentation about this.
I also don't see any triggers I didn't create in
SELECT * FROM information_schema.triggers;
I'm guessing ON UPDATE/ON DELETE are implemented internally as triggers (which aren't visible in pgAdmin)? Does anyone know where this is documented?
Try here:
DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER
These forms configure the firing of trigger(s) belonging to the table. A disabled trigger is still known to the system, but is not executed when its triggering event occurs. For a deferred trigger, the enable status is checked when the event occurs, not when the trigger function is actually executed. One can disable or enable a single trigger specified by name, or all triggers on the table, or only user triggers (this option excludes internally generated constraint triggers such as those that are used to implement foreign key constraints or deferrable uniqueness and exclusion constraints). Disabling or enabling internally generated constraint triggers requires superuser privileges; it should be done with caution since of course the integrity of the constraint cannot be guaranteed if the triggers are not executed.
I am new to Redshift when pushing the data in Redshift, where created the primary key as Vin(Vehicle Identification Number). Even when pushing the same key twice not getting any constraint exception instead same data being saved as record.
And when doing with Foreign key constraint again getting the same issue. Am I missing any configurations for enabling the contrints in db ?
From the AWS documentation:
Define primary key and foreign key constraints between tables wherever appropriate. Even though they are informational only, the query optimizer uses those constraints to generate more efficient query plans.
Do not define primary key and foreign key constraints unless your application enforces the constraints. Amazon Redshift does not enforce unique, primary-key, and foreign-key constraints.
If I read this information correctly, the workaround you should follow is to check in your application layer that each VIN number to be inserted is unique.
I am learning Sequelize and models' foreign keys, however I don't understand what's the purpose deferable field
It will create a foreign key that will check the constraints
I don't understand what's constraints(limitations) here. should I define it? I already viewed the code on official docs but It's no help and can't understand its' usage. Would appreciate if someone help me understand.
The docs mention:
A collection of properties related to deferrable constraints. It can
be used to make foreign key constraints deferrable and to set the
constraints within a transaction. This is only supported in
PostgreSQL.
So, that's your hint to google for postgres foreign key deferrable or similar. The postgres docs say:
SET CONSTRAINTS sets the behavior of constraint checking within the
current transaction. IMMEDIATE constraints are checked at the end of
each statement. DEFERRED constraints are not checked until transaction
commit. Each constraint has its own IMMEDIATE or DEFERRED mode.
Upon creation, a constraint is given one of three characteristics:
DEFERRABLE INITIALLY DEFERRED, DEFERRABLE INITIALLY IMMEDIATE, or NOT
DEFERRABLE. The third class is always IMMEDIATE and is not affected by
the SET CONSTRAINTS command. The first two classes start every
transaction in the indicated mode, but their behavior can be changed
within a transaction by SET CONSTRAINTS.
Unpacking that: deferrable means you can "defer" the checking of foreign key constraints til the end of a transaction. (Transactions, by the way, are basically "groups of queries" that either all succeed, or, if one of them fails, all the others are rolled back too.)
Let's take a contrived example: imagine you have a blogs table that has a foreign key that points to a categories table. When you insert a new blog post, the category it links to must exist - otherwise that blogs to categories foreign key constraint will fail. BUT... if we use the deffered feature, then we could do something like this (in psuedo-code):
1. Being a transaction
2. Tell postgres to use deferred foreign key constraints for this transaction
3. Insert a blog that links to the "Hello World" category (which does not yet exist)
3a. (Note this is where Postgres would normally check the foreign key constraint and fail)
4. Insert the "Hello World" Category
5. Commit the transaction
6. Because we're using the DEFERRED feature, the foreign key check
will happen now, at the end of the transaction, instead of at 3a,
and it will succeed, because "Hello Wolrd" category now exists!
To cut a long story short, you should leave out the deferrable key (or set it to false) unless you know you need it.
From http://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html
Currently, cascaded foreign key actions do not activate triggers.
Does this work in MariaDB?
According to the documentation, it seems that it doesn't work in MariaDB either:
The following restrictions apply to triggers.
[...]
Triggers are not activated by foreign key actions.
"Foreign key actions" refers to the action to perform (RESTRICT, CASCADE, SET NULL, NO ACTION, SET DEFAULT) on the rows in the current table which references deleted or updated rows in the referenced table.
Also see related bugs:
MySQL: https://bugs.mysql.com/bug.php?id=11472
MariaDB: https://jira.mariadb.org/browse/MDEV-19402