| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash |
| Date: | 2023-02-23 18:53:34 |
| Message-ID: | 586533.1677178414@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> Hmm ... this doesn't look very much like what I was imagining. Let
> me draft a prototype and we can compare.
Here's what I was thinking about. I didn't bother adding regression
test cases yet, but it fixes both of the symptoms Alexander found.
This looks pretty workable to me, and in particular I think it'd be
safe to backpatch (with some fields moved to the end of their structs
to satisfy ABI worries). We could then revert 3f7323cbb et al
in the back branches.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v1-use-private-output-array-for-MULTIEXPR.patch | text/x-diff | 16.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-02-23 19:48:05 | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) |
| Previous Message | Dean Rasheed | 2023-02-23 12:00:30 | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |