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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers