Postgres SQL dropping table drops all dependent views? - sql

In postgres when I drop a table it is dropping all views that depend upon it. Is there a way to persist the views so that they dont get dropped
Note: the table will be regenerated on daily basis with new data.

From PostgreSQL documentation
DROP TABLE always removes any indexes, rules, triggers, and constraints that exist for the target table. However, to drop a table that is referenced by a view or a foreign-key constraint of another table, CASCADE must be specified. (CASCADE will remove a dependent view entirely, but in the foreign-key case it will only remove the foreign-key constraint, not the other table entirely.)

Try TRUNCATE TABLE / CREATE TABLE IF NOT EXISTS instead of DROP.

Related

drop all constraints in a postgresql table - drop cascade

I have 21 tables in my database. However, there are some issues with the table schema (as we are trying to improve our data model). I already referred this post but it is for SQL server.
Currently, just for validation purpose, I would like to upload data inside them.
However, some ill-defined constraints are causing trouble.
So, I would like to delete all constraints only (from all tables) like Foreign key, check , unique, PK, Index etc.
How can I do this?
Currently I tried the below
ALTER TABLE subject
DROP CONSTRAINT subject_details_pk CASCADE;
ALTER TABLE subject
DROP CONSTRAINT subject_foreign_fk CASCADE;
As you can see, I have to write line by line across different tables (and manually find out which table is parent and which table is child etc).
So, is there any other way to drop all constraints in a table? Like Drop cascade ?
Can help me with this?

Oracle 11g SQL Disable foreign key constraints and drop table

When I have issued a
ALTER TABLE table DISABLE CONSTRAINT fk1
and when I then try to drop the table
DROP TABLE table
That the constraint is still checked even though it is disabled.
Have I missed something?
You have to drop the constraints as well in order drop a table. Try the following:
DROP TABLE someTable CASCADE CONSTRAINTS;
DISABLE CONSTRAINT works for update/insert statements.
See oracle help.
Disabling Constraints
To enforce the rules defined by integrity constraints, the constraints
should always be enabled. However, consider temporarily disabling the
integrity constraints of a table for the following performance
reasons:
When loading large amounts of data into a table
When performing batch operations that make massive changes to a table
(for example, changing every employee's number by adding 1000 to the
existing number)
When importing or exporting one table at a time
You are trying to drop your table. It is not designed to for this. You need to DROP CONSTRAINTs.

TRUNCATE TABLE query unable to execute in SSIS because of foreign key

I have a table Person which contains 2 fields.In my another database i have a Participant Table(also have 2 columns).From Participant Table i have to insert values into Person Table.
but before every insertion,i want truncate the person Table.
I have try it out with linking Execute Sql task to Data flow task.But it is showing error that a Primary Foreign key relation exists there.
If I understand correctly, SSIS has nothing to do with your real problem, which is that you want to truncate a table that is referenced by a foreign key constraint. That question has already been answered: Cannot truncate table because it is being referenced by a FOREIGN KEY constraint?
If a table in sql server has foreign key references then you can't truncate. instead in your execute sql task use delete without a where clause.
delete from person_table
If you are really adamant about truncating the table, you could drop the foreign key constraints, then truncate the table then recreate the foreign key constraints. Providing of course, that the user you are running the package as has the privileges to do so.
Create an "Execute SQl" task and run DELETE FROM person
after this task, run your import.
DELETE FROM will give the same result as TRUNCATE TABLE, but if the table has a foreign key pointing to it, it cant be truncated. You have to use the delete command
You won't be able to delete either unless cascading deletes is turned on (or you delete the child records first). Why is this a problem you ask, why can't I do what I want to do? Because if you do then you may lose the integrity of the data. Suppose I have records in table2 which relate to records in table 1. Suppose further that table1 has an autogenerated id. If I could truncate that table, then I leave those records i ntable 2 hanging out without any record to reference them, they have become orphaned. Well but I'm putting the data back in you say. But then they will have new id numbers and you will still lose the relatinoship tothe related data.
Can you drop the FK and truncate and insert and recreate the FK. Yes you can but it is a poor practice and you should not unless you are also recreating those related records.
The best practice is to use a MERGE statement to update or insert depending on what you need.
In SSIS Transfer SQL Server Objects Task Set Property DeleteFirst to TRUE

What happens to index once the table got dropped?

After dropping the table, found that the index created on the columns of the dropped table is gone. I just want to know what happens after that. Could someone please explain?
What all are the others getting dropped along with table drop?
In Oracle when dropping a table
all table indexes and domain indexes are dropped
any triggers defined on the table are dropped
if table is partitioned, any corresponding local index partitions are dropped
if the table is a base table for a view or if it is referenced in a stored procedure, function, or package, then these dependent objects are invalidated but not dropped
In Postgres
DROP TABLE always removes -
1. any indexes
2. rules
3. triggers
4. constraints
that exist for the target table.
MySQL also drops table indexes when tables are dropped.
For more info, see Does dropping a table in MySQL also drop the indexes?
By default, MS Sql Server also drops indexes when a table is dropped.
(Observed in version 13.0.4206.0.)

What is the equivalent effect to Truncating a table, when the table is referenced by a foreign-key

Straight out of the MSDN docs for Sql Server 2005:
You cannot use TRUNCATE TABLE on tables that:
Are referenced by a FOREIGN KEY constraint.
Participate in an indexed view.
Are published by using transactional replication or merge replication.
I want the effect of a TRUNCATE (specifically the fact that it resets IDENTITY type columns), but I can't use one in my case because my table is referenced by a foreign-key elsewhere in the database.
Update: This is for a testing configuration where I am clearing out the referencing table as well, so foreign-key integrity is a non-issue.
What other ways are there to get around this?
You can delete all the rows and then do a DBCC CHECKIDENT (Tablename, RESEED, 0) to reset the identity seed
But again DELETE is fully logged while TRUNCATE is minimally logged and will be many times faster
Another option is to drop the foreign key constrains then do a truncate and then recreating the foreign key constraints
The fact that it is refernced by a foreign key is the clue you need to not truncate a table or you would be creating orphaned records. This is why truncate table is not allowed if a foreign key exists.
The correct process is to first delete the refernced records, if any, then drop the FK constraint, then truncate the table then reinstate the fk constraint. If you skip step one, you will create a data integrity nightmare where the record pointing to oldid 100 is not pointing to the new record that happens to get assigned to 100 and it isn;t the record it should match to.
You can drop the foreign key, truncate the table, and then recreate the foreign key.
You will need to drop the constraint, trunc the table, and then add the constraint back. However, you should be very careful with this. If there are rows in the table that you are dropping the FK reference to you will not be able to add it until those rows are deleted or the FK column in the other table is clear.