| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Luis Carril <luis(dot)carril(at)swarm64(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, PG Bug reporting form <noreply(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Subject: | Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction |
| Date: | 2018-12-21 07:51:23 |
| Message-ID: | 20181221075123.GA6876@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Dec 21, 2018 at 02:10:10PM +0900, Etsuro Fujita wrote:
> My point here is that if doing so, we would have 3 versions in PG10,
> PG11, and HEAD, which would make back-patching complicated. So my
> taste would be to fix this on HEAD the same way as PG11, but I'm not
> against using RELKIND_CAN_HAVE_STORAGE on HEAD.
The conflicts would be a bit annoying yes, still those are minimal so
I would still use the macro on HEAD. Let's see if others have an
opinion. We will have a divergence between v10 and v11 anyway as v11
has added support for COPY with foreign tables, and v10 has added
support for COPY with views.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimír Houba ml. | 2018-12-21 14:35:32 | JSON_POPULATE_RECORDSET empty array bug |
| Previous Message | Etsuro Fujita | 2018-12-21 05:10:10 | Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction |