I wrote:
> Noah Misch <n...@leadboat.com> writes:
>> equalfuncs.c has been using COMPARE_COERCIONFORM_FIELD() to ignore
>> differences
>> in fields of this type. Does this spot have cause to depart from the
>> pattern?
> Oversight, I think. Will fix.
After looking closer, I see that there are a couple of very very minor
ways in which parse analysis changes behavior based on the value of
FuncCall.funcformat:
* transformRangeFunction won't apply the appropriate transformation to
a multiple-argument unnest() unless the format is COERCE_EXPLICIT_CALL.
(This is likely a no-op, though, as no grammar production that emits
COERCE_SQL_SYNTAX could apply to the function name "unnest".)
* ParseFuncOrColumn will not believe that a FuncCall could_be_projection
unless the format is COERCE_EXPLICIT_CALL. This is next door to a no-op,
since other restrictions such as nargs == 1 would usually suffice to
reject COERCE_SQL_SYNTAX calls, but maybe there are corner cases where
it'd matter.
So if you wanted to be picky you could claim that within FuncCall,
funcformat is semantically significant and thus that equalfuncs.c is
coded correctly. Nonetheless I'm inclined to think that it'd be better
to use COMPARE_COERCIONFORM_FIELD here. I'm quite sure I didn't make
the above analysis when I wrote the code; using COMPARE_SCALAR_FIELD
was just reflex.
We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing
these two tests of the funcformat value, but on the whole I doubt that
would be better.
BTW, I'm not sure any of this matters anyway; do we ever use equal()
on raw parse trees, except for debug purposes?
Thoughts?
regards, tom lane
