BUG #17668: Query normalization generates multiple queryId:s for calls to the same procedure

The following bug has been logged on the website:

Bug reference: 17668
Logged by: Marcus Kempe
Email address: marcus(dot)kempe(at)gmail(dot)com
PostgreSQL version: 14.5
Operating system: Linux
Description:

Consider the following case:

postgres=# create function test(x bigint) returns void language sql as $$
select x ;$$;
CREATE FUNCTION
postgres=# select test(1);
test
------

(1 row)

postgres=# select calls,userid,dbid,queryid,query from
public.pg_stat_statements where query like 'select test%';
calls | userid | dbid | queryid | query
-------+--------+-------+----------------------+-----------------
1 | 10 | 13757 | -8729651821477628722 | select test($1)
(1 row)

postgres=# select test(12345678910); -- larger that INTMAX.
test
------

(1 row)

postgres=# select calls,userid,dbid,queryid,query from
public.pg_stat_statements where query like 'select test%';
calls | userid | dbid | queryid | query
-------+--------+-------+----------------------+-----------------
1 | 10 | 13757 | -8729651821477628722 | select test($1)
1 | 10 | 13757 | 1452143938866253601 | select test($1)
(2 rows)

So given the above 2 calls for the same function, there are 2 different
queryIds generated, seemingly based on the fact that in the first case the
parameter can be cast to integer, and in the second case it can not.

I would have expected both calls to be normalized and fingerprinted to one
and the same queryId.

This behavior was similar even before queryjumble.c was introduced in PG14.