2014-08-08 2:13 GMT+02:00 Josh Berkus <j...@agliodbs.com>: > 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 Regards Pavel > > -- > Josh Berkus > PostgreSQL Experts Inc. > http://pgexperts.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
