On 21 December 2012 09:29, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 21 December 2012 08:56, Simon Riggs <simon@2ndquadrant.com> wrote:
>> It's unreasonable for people to demand a feature yet provide no
>> guidance to the person trying (hard) to provide that feature in a
>> sensible way. If people genuinely believe case (2) is worth pursuing,
>> additional work and input is needed so that KaiGai can make changes in
>> time for the 9.3 deadline. Please read what KaiGai has said and
>> respond. Since there are so many people reading this thread and
>> wanting (2), that seems reasonable to expect.
>>
>> What I have proposed is that I work on the review for case (1) and
>> then if we solve (2) that can go in also. I don't think its reasonable
>> to reject the whole feature because of unresolved difficulties around
>> one use case, which is what will happen if this is seen as merely a
>> debate about defaults.
>>
>
> One comment on the code itself -- I think it needs some locking of
> rows from the subquery to ensure correct concurrency behaviour when
> there are multiple transactions doing updates at the same time.
>
Another comment -- the use of the RangeTblEntry structure in the new
code is a bit odd. It seems to be creating an RTE that is both an
RTE_RELATION and an RTE_SUBQUERY at the same time. I think it would be
cleaner to just add a new RTE for the subquery (cf. the
trigger-updatable view code in ApplyRetrieveRule).
Regards,
Dean
