On Thu, Sep 14, 2017 at 1:05 PM, Alvaro Herrera
wrote:
> 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,
On 2017-09-14 12:05:37 +0200, Alvaro Herrera wrote:
> This sounds terrible.
Welcome to the life of writing extensions.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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
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. But when we do DROP EXTENSION, the event triggers don't get fired
On Wed, Sep 13, 2017 at 12:12 AM, Michael Paquier wrote:
>
> Foreign tables do not have physical storage assigned to by default. At
> least heap_create() tells so, create_storage being set to false for a
> foreign table. So there is nothing to clean up normally. Or is
On Wed, Sep 13, 2017 at 2:40 AM, Hadi Moshayedi wrote:
> Motivation for this patch is that some FDWs (notably, cstore_fdw) try
> utilizing PostgreSQL internal storage. PostgreSQL assigns relfilenode's to
> foreign tables, but doesn't clean up storage for foreign tables when
>
Motivation for this patch is that some FDWs (notably, cstore_fdw) try
utilizing PostgreSQL internal storage. PostgreSQL assigns relfilenode's to
foreign tables, but doesn't clean up storage for foreign tables when
dropping tables. Therefore, in cstore_fdw we have to do some tricks to
handle