On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> One reason we should support local triggers is that not all the data
> source of FDW support remote trigger. It required FDW drivers to
> have RDBMS as its backend, but no realistic assumption.
> For example, file_fdw is unavailable to implement remote triggers.
True, but gosh, updates via file_fdw are gonna be so slow I can't
believe anybody'd use it for something real....
> One thing I'd like to know is, where is the goal of FDW feature.
> It seems to me, FDW goes into a feature to manage external data
> set as if regular tables. If it is right understanding, things we try to
> support on foreign table is things we're supporting on regular tables,
> such as triggers.
I generally agree with that.
> We often have some case that we cannot apply fully optimized path
> because of some reasons, like view has security-barrier, qualifier
> contained volatile functions, and so on...
> Trigger may be a factor to prevent fully optimized path, however,
> it depends on the situation which one shall be prioritized; performance
> or functionality.
Sure. I mean, I guess if there are enough people that want this, I
suppose I ought not stand in the way. It just seems like a lot of
work for a feature of very marginal utility.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
