Re: [SQL] Function to total reset a schema
I would hope you have readily at hand the ddl for the schema in question. Then it's simply a matter of drop schema cascade and re-run you ddl scripts. Surfing wrote: Hi all, I need to write a function that totally empty a schema. So I have written a TRUNCATE statement for each table and set to 0 each sequence. Btw, it could be good to execute a vacuum statement on each table, but from within the function this is not allowed. Is there a way to obtain the same result in another way (without using the vacuum)? Thanks -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Function to total reset a schema
Hi all, I need to write a function that totally empty a schema. So I have written a TRUNCATE statement for each table and set to 0 each sequence. Btw, it could be good to execute a vacuum statement on each table, but from within the function this is not allowed. Is there a way to obtain the same result in another way (without using the vacuum)? Thanks -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Re: Order of evaluation in triggers for checks on inherited table partitions
On 2011-05-27, Kevin Crain wrote: > I am trying to create a trigger on updates to a table that is > partitioned. The child tables are partitioned by month and include > checks on a timestamp field. > However when I try to update an existing record with a > timestamp that would place it in a child table different from the > child table it is in I get an error due to the check on the child > table it is currently in. My best guess as to what is happening is > that the trigger is evaluating the check before it evaluates the > trigger function and thus cannot tell that the update to the original > table should never take place. I have included an example below. The > error that results is "new row for relation "t_foo_2011_6" violates > check constraint "t_foo_2011_6_f_timestamp_check"" the problem is the check is running before the trigger. perhaps you can use a rule instead of a trigger? -- ⚂⚃ 100% natural -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
