Re: Another problem with result type selection in inline_function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Another problem with result type selection in inline_function
Date
Msg-id 26271.1178044732@sss.pgh.pa.us
Whole thread Raw
In response to Another problem with result type selection in inline_function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> I think the correct thing is to do nothing, and assume the expanded
> expression must have the right type already, if the function is declared
> to return a pseudotype.  The only pseudotypes allowed as SQL-function
> results are RECORD, VOID, and polymorphic, and this seems OK and maybe
> even required in each case.  But having gotten this wrong once already,
> maybe I better call for comments...

Make that 0 for 2 :-(.  On closer inspection the correct patch seems to
be just to use "result_type", ie the result type the function call node
was already labeled with, not funcform->prorettype (the function's
declared result type).  This can be seen to be correct from two
arguments:

1. The whole point of the RelabelType insertion is to ensure that the
exposed type of the expression tree (as reported by exprType say)
remains the same as before.  And "result_type" is exactly what it was
before.

2. result_type, not prorettype, is in fact what check_sql_fn_retval()
was checking against.  That Assert was intended to back up that we were
in sync with check_sql_fn_retval(), but we weren't.

So this is just a pure thinko in the previous patch.  Sigh.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Heap page diagnostic functions
Next
From: Heikki Linnakangas
Date:
Subject: Re: Heap page diagnostic functions