Обсуждение: Change seconds argument of make_*() functions to numeric

Along with the discussed change of the return type of EXTRACT from 
float8 to numeric [0], I was looking around what other date/time APIs 
might be using float arguments or return values.  The only thing left 
appears to be the functions make_time, make_timestamp, make_timestamptz, 
and make_interval, which take an argument specifying the seconds, which 
has type float8 right now.  I'm proposing the attached patch to change 
that to numeric.

Can we change the arguments, as proposed here, or do we need to add 
separate overloaded versions and leave the existing versions in place?

[0]: 
https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> Along with the discussed change of the return type of EXTRACT from 
> float8 to numeric [0], I was looking around what other date/time APIs 
> might be using float arguments or return values.  The only thing left 
> appears to be the functions make_time, make_timestamp, make_timestamptz, 
> and make_interval, which take an argument specifying the seconds, which 
> has type float8 right now.  I'm proposing the attached patch to change 
> that to numeric.

I don't really see the point here.  Since the seconds value is constrained
to 0..60 and will be rounded off to microseconds, you would have to work
seriously hard to find an example where float8 roundoff error could be
a problem.  I don't think we should take whatever speed and compatibility
hit is implied by using numeric instead of float8.

(make_interval in theory could be an exception, since it doesn't constrain
the range of seconds values.  But I still don't believe there's a problem
in practice.)

> Can we change the arguments, as proposed here, or do we need to add 
> separate overloaded versions and leave the existing versions in place?

Since there's no implicit float8 to numeric cast, removing the existing
versions could quite easily cause failures of queries that work today.

            regards, tom lane