On 21 December 2012 09:29, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 21 December 2012 08:56, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
