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
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
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
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
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
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
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
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
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
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
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 ?
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
] 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
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
Hello.
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.
The attached patch does not contain regression tests or documentation yet, a
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
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,
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
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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:
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
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
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 implement just that.
For row-level triggers, it seems more complicated. From
35 matches
Mail list logo
