(2014/12/13 1:17), Tom Lane wrote: > Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: >>> (2014/12/12 10:37), Tom Lane wrote: >>>> Yeah, this is clearly a thinko: really, nothing in the planner should >>>> be using get_parse_rowmark(). I looked around for other errors of the >>>> same type and found that postgresGetForeignPlan() is also using >>>> get_parse_rowmark(). While that's harmless at the moment because we >>>> don't support foreign tables as children, it's still wrong.
>> In order >> to get the locking strength, I think we need to see the RowMarkClauses >> and thus still need to use get_parse_rowmark() in >> postgresGetForeignPlan(), though I agree with you that that is ugly. > I think this needs more thought; I'm still convinced that having the FDW > look at the parse rowmarks is the Wrong Thing. However, we don't need > to solve it in existing branches. With 9.4 release so close, the right > thing is to revert that change for now and consider a HEAD-only patch > later. OK > (One idea is to go ahead and make a ROW_MARK_COPY item, but > add a field to PlanRowMark to record the original value. +1 > We should > probably also think about allowing FDWs to change these settings if > they want to. This is not clear to me. Maybe I'm missing something, but I think that the FDW only needs to look at the original locking strength in GetForeignPlan(). Please explain that in a little more detail. Thanks, Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
