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.1618411...@sss.pgh.pa.us and
> > postgr.es/m/1471865.1734212...@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.
