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

On Mon, Mar 21, 2022 at 4:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> What's not clear to me though is whether that's the full
> extent of problematic cases.

What other cases were you thinking of?

Allowing parameters here just seems wrong to me. Rejecting them
outright is strictly better than what we have today IMV.

Perhaps there are other problems, but ISTM that they can be treated as
independent problems.

> (Picking a user-friendly wording for the
> error message might be hard too.)

True (I struggle with that stuff at the best of times). OTOH beating
the current behavior might not be too hard.

I don't feel strongly about any of this -- just providing you with the
context, in case it helps.

I suspect that most users work out how to fix their INSERT statement
intuitively already, without seeing any HINT. Sometimes it's easy to
do that because it's your particular application, and involves one
particular table that only has one or two partial unique indexes. It's
probably much harder to describe what's going on (or what the user
ought to be doing) in very general terms, while actually getting the
idea across. (Also, it doesn't take that much trial and error to
figure out what to do here.)

--
Peter Geoghegan