Re: Modernizing SQL functions' result type coercions

On 28/11/2019 00:57, Tom Lane wrote:
> Hence, the attached patch rearranges things so that we'll allow
> any case where the parser's standard coercion logic can find an
> assignment-level coercion, including typmod coercion if needed.
> In a green field I might've argued for restricting this to
> implicit coercions; but since some of the standard binary-compatible
> casts are assignment-level, that would risk breaking applications
> that work today.  It's really safe enough though, just as assignment
> coercions are fine in INSERT: there's no possible confusion about
> which conversion is appropriate.

Makes sense. That's a nice usability improvement.

> This required some adjustments of check_sql_fn_retval's API.
> I found that pulling out the determination of the result tupdesc
> and making the callers do that was advisable: in most cases, the
> caller has more information and can produce a more accurate tupdesc
> (eg by calling get_call_result_type not get_func_result_type).
> I also pulled out creation of the JunkFilter that functions.c
> wants (but none of the other callers do); having it in just one
> place seems simpler.  A nice side-effect of these changes is that
> we can inline SQL functions in some cases where that wasn't
> possible before.

In init_sql_fcache(), one comment says that the junkfilter is 
responsible for injecting NULLs for dropped columns, and a later comment 
says that the junk filter gets "rid of any dropped columns". That seems 
contradictory; which is it? Or does "get rid of" mean "set to NULL"?

Other than that, looks good to me.

- Heikki