| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | ashutosh(dot)bapat(at)enterprisedb(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Another oddity in handling of WCO constraints in postgres_fdw |
| Date: | 2017-10-06 06:48:13 |
| Message-ID: | 9b736946-253e-2591-4139-bdd8a321973f@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017/10/05 20:06, Kyotaro HORIGUCHI wrote:
> Since WCO ensures finally inserted values, we can't do other than
> acturally requesting for the values.
I think so too.
> So just merging WCO columns
> to RETURNING in deparsed query is ok. But can't we concatenate
> returningList and withCheckOptionList at more higher level?
> Specifically, just passing calculated used_attr to
> deparse(Insert|Update)Sql instead of returningList and
> withCheckOptionList separately. Deparsed queries anyway forget
> the origin of requested columns.
We could do that, but I think that would need a bit more code to
postgresPlanForeignModify including changes to the deparseDeleteSql API
in addition to the deparse(Insert|Update)Sql APIs. I prefer making high
level functions simple, so I'd vote for just passing withCheckOptionList
separately to deparse(Insert|Update)Sql, as proposed in the patch.
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2017-10-06 06:48:47 | Re: Partition-wise join for join between (declaratively) partitioned tables |
| Previous Message | Amit Khandekar | 2017-10-06 06:33:59 | Re: Parallel Append implementation |