From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres_fdw join pushdown - wrong results with whole-row reference |
Date: | 2016-06-28 03:30:51 |
Message-ID: | 80dbb41c-9f6d-6887-d274-267464d88a95@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/06/27 18:56, Ashutosh Bapat wrote:
> On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>> wrote:
> I found another bug in error handling of whole-row references in
> join pushdown; conversion_error_callback fails to take into account
> that get_relid_attribute_name(Oid relid, AttrNumber attnum) can't
> handle whole-row references (ie, attnum=0), in which case that would
> cause cache lookup errors. Attached is a small patch to address
> this issue.
> Do you have any testcase reproducing the bug here? It would be good to
> include that test in the regression.
Done.
> There is a always a possibility that a user would create a table (which
> can be used as target for the foreign table) with column named
> 'wholerow', in which case s/he will get confused with this error message.
By grepping I found that there are error messages that use "whole-row
table reference", "whole-row reference", or "wholerow", so the use of
"wholerow" seems to me reasonable. (And IMO I think "wholerow" would
most likely fit into that errcontext().)
Best regards,
Etsuro Fujita
Attachment | Content-Type | Size |
---|---|---|
postgres-fdw-conv-error-callback-v2.patch | binary/octet-stream | 2.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-28 03:40:37 | Re: A couple of cosmetic changes around shared memory code |
Previous Message | Michael Paquier | 2016-06-28 03:26:00 | Re: Broken handling of lwlocknames.h |