Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded
Date
Msg-id CAH2-Wzmbdn1DdJoY5G-_7WuwiqLJM8tWdJaMMsPX8gimLPSdZg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Mar 21, 2022 at 4:03 PM Tom Lane <tgl@sss.pgh.pa.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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded
Next
From: Tom Lane
Date:
Subject: Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded