On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
