Re: [PATCH] Call RelationDropStorage() for broader range of object drops.

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Hadi Moshayedi <hadi(at)citusdata(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Call RelationDropStorage() for broader range of object drops.
Date: 2017-09-14 10:05:37
Message-ID: 20170914100537.ayaw77hk2xqxiwfe@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hadi Moshayedi wrote:
> To provide more context, in cstore_fdw creating the storage is easy, we
> only need to hook into CREATE FOREIGN TABLE using event triggers. Removing
> the storage is not that easy, for DROP FOREIGN TABLE we can use event
> triggers.

This all sounds a little more complicated than it should ... but since
FDW are not really IMO the right interface to be implementing a
different storage format, I'm not terribly on board with supporting this
more completely. So what you're doing now is probably acceptable.

> But when we do DROP EXTENSION, the event triggers don't get fired
> (because they have already been dropped),

This however sounds like a silly design bug ... surely the event
triggers should have been fired when the table is dropped, before
dropping the event triggers themselves. I can't offhand think of any
good way to fix that, however.

> so to handle DROP EXTENSION, we need to hook into the process utility
> hook. Now to implement this, (1) we get a list of all cstore tables
> (2) call postgres's utility hook, (3) if #2 succeeds clean-up all
> cstore table storage's. But when #3 happens the relation isn't there
> anymore, so we create a pseudo-relation [1] and call
> RelationDropStorage().

This sounds terrible.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-09-14 10:19:03 Re: Surjective functional indexes
Previous Message Kyotaro HORIGUCHI 2017-09-14 10:02:18 Re: Race between SELECT and ALTER TABLE NO INHERIT