|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Cc:||Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>|
|Subject:||Re: Modernizing SQL functions' result type coercions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Tom Lane||2020-01-08 15:22:55||Re: Modernizing SQL functions' result type coercions|
|Previous Message||Tom Lane||2020-01-08 15:04:17||Re: src/test/recovery regression failure on bionic|