Re: [PATCH] postgres_fdw extension support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] postgres_fdw extension support
Date
Msg-id 3505.1443622007@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] postgres_fdw extension support  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: [PATCH] postgres_fdw extension support  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-hackers
Paul Ramsey <pramsey@cleverelephant.ca> writes:
> Hm. Wouldn't it be just fine if only the server is able to define a 
> list of extensions then? It seems to me that all the use-cases of this 
> feature require to have a list of extensions defined per server, and 
> not per fdw type. This would remove a level of complexity in your 
> patch without impacting the feature usability as well. I would 
> personally go without it but I am fine to let a committer (Tom?) put a 
> final judgement stamp on this matter. Thoughts? 

Maybe I'm missing something, but I had envisioned the set of
safe-to-transmit extensions as typically being defined at the
foreign-server level.  The reason being that you are really declaring two
things: one is that the extension's operations are reproducible remotely,
and the other is that the extension is in fact installed on this
particular remote server.  Perhaps there are use-cases for specifying it
as an FDW option or per-table option, but per-server option seems by
far the most plausible case.

Also, isn't this whole thing specific to postgres_fdw anyway?  I don't
follow your reference to fdw type.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Idea for improving buildfarm robustness
Next
From: Kouhei Kaigai
Date:
Subject: Re: [Proposal] Table partition + join pushdown