Re: proposal: simple date constructor from numeric values

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Peter Eisentraut escribi:
>> On 7/1/13 3:47 AM, Pavel Stehule wrote:
>>> CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int
>>> DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0);
>>
>> If we are using integer datetime storage, we shouldn't use floats to
>> construct them.

> I think this is wrong. Datetime storage may be int, but since they're
> microseconds underneath, we'd be unable to specify a full-resolution
> timestamp if we didn't have float ms or integer s. So either the
> seconds argument should allow fractions (probably not a good idea), or
> we should have another integer argument for microseconds (not
> milliseconds as the above signature implies).

FWIW, I'd vote for allowing the seconds to be fractional. That's the
way the user perceives things:

regression=# select '12:34:56.789'::time;
time
--------------
12:34:56.789
(1 row)

Moreover, an integer microseconds argument would be a shortsighted idea
because it wires the precision limit into the function API. As long as
we make the seconds argument be float8, it will work fine even when the
underlying precision switches to, say, nanoseconds.

And lastly, those default arguments are a bad idea as well. There's no
reasonable use-case for make_time(12); that's almost certainly an error.
Even more so for make_time(). While you could make some case for
make_time(12,34) being useful, I don't think it buys much compared
to writing out make_time(12,34,0), and having just one function
signature is that much less cognitive load on users.

So my vote is for make_time(hour int, min int, sec float8).

regards, tom lane