|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
(2018/07/26 21:11), Etsuro Fujita wrote:
> (2018/07/26 5:27), Robert Haas wrote:
>> Well, I could have the wrong idea here, but I tend to think allowing
>> for ConvertRowTypeExpr elsewhere won't be that bad.
> I still don't like that because in my opinion, changes needed for that
> would not be localized, and that would make code complicated more than
> As I mentioned in a previous email, another idea to avoid that would be
> to adjust tlists for children at path creation time, not plan creation
> time; we could adjust the tlist for each of subpaths accumulated for an
> Append/MergeAppend path in add_paths_to_append_rel called from
> set_append_rel_pathlist or generate_partitionwise_join_paths, with
> create_projection_path adding ConvertRowTypeExpr. It seems unlikely that
> performing create_projection_path to such a subpath would change its
> property of being the cheapest, so it would be safe to adjust the tlists
> that way. This would not require making create_plan complicated anymore.
> I might be missing something, though.
I updated the patch that way. Updated patch attached. I fixed a bug
and did a bit of cleanups as well.
|Next Message||Etsuro Fujita||2018-08-01 11:46:48||Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.|
|Previous Message||Emre Hasegeli||2018-08-01 11:44:03||Re: [PATCH] Improve geometric types|