On 2015/12/23 8:45, Peter Geoghegan wrote:
> On Tue, Dec 22, 2015 at 3:38 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> In my opinion a term more closely coupled to the concrete syntax would
>> be easier to understand. I have no objection to referring to the
>> *process* of trying to deduce a suitable index from the ON CONFLICT
>> clause as "inference". But calling the ON CONFLICT clause an
>> "inference specification" is, in my opinion, an unnecessary oblique
>> way of referring to it. If you renamed InferenceElem to
>> InsertOnConflictElem, I think that would be strictly more clear.
>
> The documentation uses the term "unique index inference" to introduce
> the concept. It then uses "inference" as a shorthand a couple of times
> when the context is very well established. So I don't see that I've
> done that at all.
>
> As for the one user-visible error messages where the term "inference
> specification" is used, that message also has a hint that draws
> particular attention to what is meant:
>
> if (onConflictClause->action == ONCONFLICT_UPDATE && !infer)
> ereport(ERROR,
> (errcode(ERRCODE_SYNTAX_ERROR),
> errmsg("ON CONFLICT DO UPDATE requires inference
> specification or constraint name"),
> errhint("For example, ON CONFLICT (column_name)."),
> parser_errposition(pstate,
> exprLocation((Node *) onConflictClause))));
>
> (There is one appearance of "inference specification" in a defensive
> elog() call).
>
> So I still don't understand why anyone takes issue with this. It's a
> total mystery to me.
IMHO, a term like "arbiter (index) specification" would be clear as well.
I don't deny though that there is the process of inference ("choosing" as
INSERT documentation calls it).
Thanks,
Amit