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.
--
Peter Geoghegan