Re: Converting contrib SQL functions to new style

On Wed, Jan 08, 2025 at 11:32:00AM +0900, Michael Paquier wrote:
> On Mon, Jan 06, 2025 at 11:04:28AM -0800, Noah Misch wrote:
> > Per postgr.es/m/3489827.1618411777@sss.pgh.pa.us and
> > postgr.es/m/1471865.1734212070@sss.pgh.pa.us one requirement for migrating to
> > SQL-standard function bodies is removing these inexact-match function and
> > operator calls.  Here, one could either write pg_catalog.generate_series or
> > make the argument types match exactly.
> 
> Thanks for the report.
> 
> Tom has used casts for xml2 in 667368fd26de, and also combined some
> pg_catalog for schema qualifications in citext for example.  In this
> case forcing the data types seems more elegant to me.

> --- a/contrib/pg_freespacemap/pg_freespacemap--1.2--1.3.sql
> +++ b/contrib/pg_freespacemap/pg_freespacemap--1.2--1.3.sql
> @@ -9,5 +9,5 @@ RETURNS SETOF RECORD
>  LANGUAGE SQL PARALLEL SAFE
>  BEGIN ATOMIC
>    SELECT blkno, pg_freespace($1, blkno) AS avail
> -  FROM generate_series(0, pg_relation_size($1) / current_setting('block_size')::bigint - 1) AS blkno;
> +  FROM generate_series(0::bigint, pg_relation_size($1) / current_setting('block_size'::text)::bigint - 1::bigint) AS
blkno;
>  END;

It's more optimal to write '0'::bigint.  That generates a CONST node, whereas
0::bigint generates a FUNCEXPR calling the cast function.  No other concerns.