On 08/07/2014 04:48 PM, Tom Lane wrote: > plpgsql is not efficient at all about coercions performed as a side > effect of assignments; if memory serves, it always handles them by > converting to text and back. So basically the added cost here came > from float8out() and float4in(). There has been some talk of trying > to do such coercions via SQL casts, but nothing's been done for fear > of compatibility problems.
Yeah, that's a weeks-long project for someone. And would require a lot of tests ...
It is not trivial task. There are two possible direction and both are not trivial (I am not sure about practical benefits for users - maybe for some PostGIS users - all for some trivial very synthetic benchmarks)
a) we can enhance plpgsql exec_assign_value to accept pointer to cache on tupmap - it is relative invasive in plpgsql - and without benefits to other PL
b) we can enhance SPI API to accept target TupDesc (with reusing transformInsertRow) - it should be little bit less invasive in plpgsql, but require change in SPI API. This path should be much more preferable - it can be used in SQL/PSM and it can be used in lot of C extensions - It can be more simply to specify expected TupDesc than enforce casting via manipulation with SQL string. I missed this functionality more times. I designed PL/pgPSM with same type strict level as PostgreSQL has - and this functionality can simplify code.
PLpgSQL uses spi_prepare_params .. we can enhance this function or we can introduce new spi_prepare_params_enforce_result_type
