Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded |
Дата | |
Msg-id | CAH2-Wznwk8ObL233+4jbHc2Bp0S9vW9MaBrM_fG-_0kkzRkaCQ@mail.gmail.com обсуждение исходный текст |
Ответ на | 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>) |
Список | pgsql-bugs |
On Mon, Mar 21, 2022 at 4:27 PM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-bugs по дате отправления: