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
