Re: Modernizing SQL functions' result type coercions

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
Date: 2020-01-08 15:06:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
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