Re: [HACKERS] Triggers on foreign tables

2014-03-24 Thread Ronan Dunklau
Le dimanche 23 mars 2014 02:44:26 Noah Misch a écrit : On Tue, Mar 18, 2014 at 09:31:06AM +0100, Ronan Dunklau wrote: Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit : (1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely parallels our handling for

Re: [HACKERS] Triggers on foreign tables

2014-03-23 Thread Noah Misch
On Tue, Mar 18, 2014 at 09:31:06AM +0100, Ronan Dunklau wrote: Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit : (1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely parallels our handling for INSTEAD OF triggers on views. It adds a wholerow resjunk

Re: [HACKERS] Triggers on foreign tables

2014-03-18 Thread Ronan Dunklau
Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit : I hacked on this for awhile, but there remain two matters on which I'm uncertain about the right way forward. (1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely parallels our handling for INSTEAD OF

Re: [HACKERS] Triggers on foreign tables

2014-03-18 Thread Robert Haas
On Mon, Mar 17, 2014 at 11:54 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: I hacked on this for awhile, but there remain two matters on which I'm uncertain about the right way forward. (1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely parallels our handling for

Re: [HACKERS] Triggers on foreign tables

2014-03-17 Thread Kouhei Kaigai
I hacked on this for awhile, but there remain two matters on which I'm uncertain about the right way forward. (1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely parallels our handling for INSTEAD OF triggers on views. It adds a wholerow resjunk attribute, from

Re: [HACKERS] Triggers on foreign tables

2014-03-06 Thread Ronan Dunklau
Le mercredi 5 mars 2014 22:36:44 Noah Misch a écrit : Agreed. More specifically, I see only two scenarios for retrieving tuples from the tuplestore. Scenario one is that we need the next tuple (or pair of tuples, depending on the TriggerEvent). Scenario two is that we need the tuple(s) most

Re: [HACKERS] Triggers on foreign tables

2014-03-05 Thread Noah Misch
This version looks basically good. I have some cosmetic things to sweep up before commit. One point is a bit more substantial: On Tue, Feb 04, 2014 at 01:16:22PM +0100, Ronan Dunklau wrote: Le lundi 3 février 2014 23:28:45 Noah Misch a écrit : On Sun, Feb 02, 2014 at 11:53:51AM +0100, Ronan

Re: [HACKERS] Triggers on foreign tables

2014-03-03 Thread Kohei KaiGai
I tried to check the latest (v8) patch again, then could not find problem in your design change from the v7. As Noah pointed out, it uses per query-depth tuplestore being released on AfterTriggerEndSubXact. So, may I mark it as ready for committer? 2014-03-03 15:48 GMT+09:00 Ronan Dunklau

Re: [HACKERS] Triggers on foreign tables

2014-03-03 Thread Noah Misch
On Mon, Mar 03, 2014 at 11:10:30PM +0900, Kohei KaiGai wrote: I tried to check the latest (v8) patch again, then could not find problem in your design change from the v7. As Noah pointed out, it uses per query-depth tuplestore being released on AfterTriggerEndSubXact. So, may I mark it as

Re: [HACKERS] Triggers on foreign tables

2014-03-02 Thread Ronan Dunklau
Hello. Did you have time to review the latest version of this patch ? Is there anything I can do to get this ready for commiter ? Thank you for all the work performed so far. Le mardi 4 février 2014 13:16:22 Ronan Dunklau a écrit : Le lundi 3 février 2014 23:28:45 Noah Misch a écrit : On

Re: [HACKERS] Triggers on foreign tables

2014-02-03 Thread Noah Misch
On Sun, Feb 02, 2014 at 11:53:51AM +0100, Ronan Dunklau wrote: Le jeudi 30 janvier 2014 14:05:08 Noah Misch a écrit : On Thu, Jan 23, 2014 at 03:17:35PM +0100, Ronan Dunklau wrote: What do you think about this approach ? Is there something I missed which would make it not sustainable ?

Re: [HACKERS] Triggers on foreign tables

2014-01-30 Thread Noah Misch
On Thu, Jan 23, 2014 at 03:17:35PM +0100, Ronan Dunklau wrote: - for after triggers, the whole queuing mechanism is bypassed for foreign tables. This is IMO acceptable, since foreign tables cannot have constraints or constraints triggers, and thus have not need for deferrable

Re: [HACKERS] Triggers on foreign tables

2014-01-29 Thread Kouhei Kaigai
] On Behalf Of Ronan Dunklau Sent: Thursday, January 23, 2014 11:18 PM To: Noah Misch Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Triggers on foreign tables Thank you very much for this review. The need here is awfully similar to a need of INSTEAD OF triggers on views. For them, we

Re: [HACKERS] Triggers on foreign tables

2014-01-17 Thread Noah Misch
On Tue, Jan 07, 2014 at 12:11:28PM +0100, Ronan Dunklau wrote: Since the last discussion about it (http://www.postgresql.org/message-id/cadyhksugp6ojb1pybtimop3s5fg_yokguto-7rbcltnvaj5...@mail.gmail.com), I finally managed to implement row triggers for foreign tables. For statement-level

Re: [HACKERS] Triggers on foreign tables

2013-10-16 Thread Ronan Dunklau
Le mardi 15 octobre 2013 09:47:31 Robert Haas a écrit : On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: And, I also want some comments from committers, not only from mine. +1 +1 /me pokes head up. I know I'm going to annoy people with this comment, but I

Re: [HACKERS] Triggers on foreign tables

2013-10-16 Thread Ronan Dunklau
Sorry, I might call it something like primary key, instead of 'tupleid'. Apart from whether we can uniquely identify a particular remote record with an attribute, what FDW needs here is something to identify a remote record. So, we were talking about same concept with different names. Ah,

Re: [HACKERS] Triggers on foreign tables

2013-10-16 Thread Robert Haas
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

Re: [HACKERS] Triggers on foreign tables

2013-10-16 Thread Kohei KaiGai
2013/10/16 Robert Haas robertmh...@gmail.com: 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

Re: [HACKERS] Triggers on foreign tables

2013-10-16 Thread Robert Haas
On Wed, Oct 16, 2013 at 2:20 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: True, but gosh, updates via file_fdw are gonna be so slow I can't believe anybody'd use it for something real How about another example? I have implemented a column-oriented data store with read/write capability,

Re: [HACKERS] Triggers on foreign tables

2013-10-15 Thread Robert Haas
On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: And, I also want some comments from committers, not only from mine. +1 +1 /me pokes head up. I know I'm going to annoy people with this comment, but I feel like it's going to have to be made at some point by somebody,

Re: [HACKERS] Triggers on foreign tables

2013-10-15 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: /me pokes head up. I know I'm going to annoy people with this comment, but I feel like it's going to have to be made at some point Perhaps some folks will be annoyed- I'm not annoyed, but I don't really agree. :) by somebody, so here

Re: [HACKERS] Triggers on foreign tables

2013-10-15 Thread Kohei KaiGai
2013/10/15 Robert Haas robertmh...@gmail.com: On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: And, I also want some comments from committers, not only from mine. +1 +1 /me pokes head up. I know I'm going to annoy people with this comment, but I feel like it's

Re: [HACKERS] Triggers on foreign tables

2013-10-14 Thread Kohei KaiGai
2013/10/13 Ronan Dunklau rdunk...@gmail.com: Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit : 2013/10/10 Ronan Dunklau rdunk...@gmail.com: Sorry, I'm uncertain the point above. Are you saying FDW driver may be able to handle well a case when a remote tuple to be updated is different

Re: [HACKERS] Triggers on foreign tables

2013-10-13 Thread Ronan Dunklau
Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit : 2013/10/10 Ronan Dunklau rdunk...@gmail.com: Sorry, I'm uncertain the point above. Are you saying FDW driver may be able to handle well a case when a remote tuple to be updated is different from a remote tuple being fetched on the

Re: [HACKERS] Triggers on foreign tables

2013-10-11 Thread Kohei KaiGai
2013/10/10 Ronan Dunklau rdunk...@gmail.com: Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit : 2013/9/10 Ronan Dunklau rdunk...@gmail.com: For row-level triggers, it seems more complicated. From what I understand, OLD/NEW tuples are fetched from the heap using their ctid (except for

Re: [HACKERS] Triggers on foreign tables

2013-10-10 Thread Ronan Dunklau
Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit : 2013/9/10 Ronan Dunklau rdunk...@gmail.com: For row-level triggers, it seems more complicated. From what I understand, OLD/NEW tuples are fetched from the heap using their ctid (except for BEFORE INSERT triggers). How could this be

Re: [HACKERS] Triggers on foreign tables

2013-10-09 Thread Jim Nasby
On 10/6/13 3:33 PM, Kohei KaiGai wrote: 2013/9/10 Ronan Dunklau rdunk...@gmail.com: For row-level triggers, it seems more complicated. From what I understand, OLD/NEW tuples are fetched from the heap using their ctid (except for BEFORE INSERT triggers). How could this be adapted for foreign

Re: [HACKERS] Triggers on foreign tables

2013-10-09 Thread Kohei KaiGai
What happens if someone changes the record on the foreign side between when we've read it and we do the UPDATE? Concurrency control is job of FDW driver. It has to coordinate access to the records to be fetched for update / delete. In fact, postgres_fdw add FOR UPDATE to avoid concurrent update

Re: [HACKERS] Triggers on foreign tables

2013-10-06 Thread Kohei KaiGai
2013/9/10 Ronan Dunklau rdunk...@gmail.com: For row-level triggers, it seems more complicated. From what I understand, OLD/NEW tuples are fetched from the heap using their ctid (except for BEFORE INSERT triggers). How could this be adapted for foreign tables ? It seems to me the origin of

Re: [HACKERS] Triggers on foreign tables

2013-09-16 Thread Ronan Dunklau
On Thursday 12 September 2013 12:10:01 Peter Eisentraut wrote: The documentation build fails: openjade:trigger.sgml:72:9:E: end tag for ACRONYM omitted, but OMITTAG NO was specified openjade:trigger.sgml:70:56: start tag was here Thank you, I took the time to install a working doc-building

Re: [HACKERS] Triggers on foreign tables

2013-09-12 Thread Peter Eisentraut
On 9/11/13 10:14 AM, Ronan Dunklau wrote: On Wednesday 11 September 2013 06:27:24 Michael Paquier wrote: As your patch is targeting the implementation of a new feature, please consider adding this patch to the next commit fest that is going to begin in a couple of days:

Re: [HACKERS] Triggers on foreign tables

2013-09-11 Thread Michael Paquier
On Tue, Sep 10, 2013 at 5:08 AM, Ronan Dunklau rdunk...@gmail.com wrote: Hello. I wanted to know what it would take to implement triggers on foreign tables. It seems that statement-level triggers can work provided they are allowed in the code. Please find attached a simple POC patch that

Re: [HACKERS] Triggers on foreign tables

2013-09-11 Thread Ronan Dunklau
On Wednesday 11 September 2013 06:27:24 Michael Paquier wrote: As your patch is targeting the implementation of a new feature, please consider adding this patch to the next commit fest that is going to begin in a couple of days: https://commitfest.postgresql.org/action/commitfest_view?id=19 I