On Tue, Dec 22, 2015 at 3:38 PM, Robert Haas <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
