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 ha
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 resj
On Mon, Mar 17, 2014 at 11:54 PM, Kouhei Kaigai 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 INSTEAD OF tri
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
> 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, fro
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) m
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, Rona
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
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 :
> H
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 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 sustaina
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
> > > deferrabl
m Project
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ronan Dunklau
> Sent: Thursday, January 23, 2014 11:18 PM
> To: Noah Misch
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS]
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-lev
On Wed, Oct 16, 2013 at 2:20 PM, Kohei KaiGai 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, using FDW APIs.
2013/10/16 Robert Haas :
> On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai 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, fil
On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai 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 impleme
> 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.
A
Le mardi 15 octobre 2013 09:47:31 Robert Haas a écrit :
> On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai 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 fe
2013/10/15 Robert Haas :
> On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai 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
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 go
On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai 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, so here go
2013/10/13 Ronan Dunklau :
> Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit :
>> 2013/10/10 Ronan Dunklau :
>
>> 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
Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit :
> 2013/10/10 Ronan Dunklau :
> 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 first stage? Or,
2013/10/10 Ronan Dunklau :
> Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit :
>> 2013/9/10 Ronan Dunklau :
>> > 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
Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit :
> 2013/9/10 Ronan Dunklau :
> > 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
> 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 up
On 10/6/13 3:33 PM, Kohei KaiGai wrote:
2013/9/10 Ronan Dunklau :
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
2013/9/10 Ronan Dunklau :
> 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 difficulty to suppo
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-bui
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:
>> https://commit
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
On Tue, Sep 10, 2013 at 5:08 AM, Ronan Dunklau 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 implement just
33 matches
Mail list logo
