| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | yaser(dot)amiri95(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded |
| Date: | 2022-03-21 23:14:21 |
| Message-ID: | CAH2-Wzmbdn1DdJoY5G-_7WuwiqLJM8tWdJaMMsPX8gimLPSdZg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Mar 21, 2022 at 4:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hm. I don't have an opinion on whether this'd be a useful case to
> support, but I agree that actually doing so is not terribly feasible.
In general the semantics of the INSERT might depend upon which
particular partial unique index the user intended for us to infer, which
would have to vary with the parameter (I suppose). Those semantics seem
wildly unreasonable to me, in roughly the same way as parameterizing
the target table's name would be.
> Perhaps a specific error message would be worth the trouble.
I'm not sure how difficult it would be offhand, so I can't commit to it now.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-03-21 23:27:33 | Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded |
| Previous Message | Tom Lane | 2022-03-21 23:03:15 | Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded |