From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Bug] Inconsistent result for inheritance and FOR UPDATE. |
Date: | 2014-12-12 02:19:52 |
Message-ID: | 23107.1418350792@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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. Will
>> fix that too.
> I don't think we need to fix that too. In order to support that, I'm
> proposing to modify postgresGetForeignPlan() in the following way [1]
> (see fdw-inh-5.patch).
My goodness, that's ugly. And it's still wrong, because this is planner
code so it shouldn't be using get_parse_rowmark at all. The whole point
here is that the rowmark info has been transformed into something
appropriate for the planner to use. While that transformation is
relatively trivial today, it might not always be so.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-12-12 02:29:38 | Re: Review of Refactoring code for sync node detection |
Previous Message | Etsuro Fujita | 2014-12-12 02:05:45 | Re: [Bug] Inconsistent result for inheritance and FOR UPDATE. |