On 23 October 2010 05:58, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote:
> On 22 October 2010 19:45, Brendan Jurd <direvus@gmail.com> wrote:
>> Without these functions (or some variation), a user wishing to
>> construct a date from integers can only assemble the date into a
>> string and then put that string through postgres' datetime parser,
>> which is totally perverse.
>
> What's wrong with to_timestamp() and to_date()? Sure, your functions
> might be marginally faster, but I don't think that it's likely to be a
> very performance sensitive area.
>
Hi Peter,
The answer to your question is in the paragraph I quoted from my OP
above. to_timestamp() and to_date() don't offer any non-retarded way
to get from integer values to datetime values. They are great if you
are coming from text, but if you already have integers they are lame.
Perhaps an example would be constructive. Would you rather do this:
datetime(2010, 10, 23, 6, 11, 0)
or this:
to_date(2010::text || '-' || 10::text || '-' || 23::text || ' ' ||
6::text || ':' || 11::text || ':' || 0::text, 'YYYY-MM-DD HH24:MI:SS')
The performance increase is nice, but as you say, this isn't likely to
be in a performance critical path. The main benefits are convenience,
simplicity and readability.
Cheers,
BJ