Re: Finding tables dropped by DROP TABLE CASCADE

From: Joe Abbate <jma(at)freedomcircle(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Finding tables dropped by DROP TABLE CASCADE
Date: 2011-08-17 02:00:59
Message-ID: 4E4B20DB.8090404@freedomcircle.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/16/2011 08:52 PM, Tatsuo Ishii wrote:
>> Presumably it would also need to invalidated if someone did ALTER
>> TABLE (which might recurse into unspecified children).
>
> Good point. For DROP TABLE/ALTER TABLE, I need to take care of its chidren.
>
>> It sort of seems like what you want to do is snoop the sinval traffic...
>
> It's hard for pgpool-II since there's no API in PostgreSQL for
> that. Maybe I will look into the system catalog to find out
> children. I'm not sure if I can deal with CASCADE by the same method
> though.

Not sure how much it will help, but I have implemented the logic to drop
dependent tables and other objects from catalog info, in Pyrseas. The
relevant code is in

https://github.com/jmafc/Pyrseas/blob/master/pyrseas/dbobject/table.py

In particular, _from_catalog() at line 375 fetches the information using
the query and inhquery SELECTs just above it. Then in diff_map()
starting at line 641 it issues the SQL to drop the various dependent
objects and tables.

If it's mostly inherited tables that you're concerned, the inhquery and
the code dealing with inhstack should be helpful.

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-08-17 02:07:56 Re: synchronized snapshots
Previous Message Jeff Davis 2011-08-17 01:54:44 Re: synchronized snapshots