| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Another way to fix inherited UPDATE/DELETE |
| Date: | 2019-02-20 10:50:42 |
| Message-ID: | 5C6D3102.6000904@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(2019/02/20 6:48), Tom Lane wrote:
> In the case of a standard inheritance or partition tree, this seems to
> go through really easily, since all the children could share the same
> returned CTID column (I guess you'd also need a TABLEOID column so you
> could figure out which table to direct the update back into). It gets
> a bit harder if the tree contains some foreign tables, because they might
> have different concepts of row identity, but I'd think in most cases you
> could still combine those into a small number of output columns.
If this is the direction we go in, we should work on the row ID issue
[1] before this?
Best regards,
Etsuro Fujita
[1] https://www.postgresql.org/message-id/1590.1542393315%40sss.pgh.pa.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2019-02-20 10:51:08 | Re: restrict pg_stat_ssl to superuser? |
| Previous Message | Matsumura, Ryo | 2019-02-20 10:40:26 | RE: SQL statement PREPARE does not work in ECPG |