Re: A Typo in regress/sql/privileges.sql

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