Re: Analysis Function - Mailing list pgsql-performance

From Tom Lane
Subject Re: Analysis Function
Date
Msg-id 14107.1276443739@sss.pgh.pa.us
Whole thread Raw
In response to Re: Analysis Function  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Analysis Function  (Magnus Hagander <magnus@hagander.net>)
List pgsql-performance
Magnus Hagander <magnus@hagander.net> writes:
> On Sun, Jun 13, 2010 at 09:38, David Jarvis <thangalin@gmail.com> wrote:
>> Does it makes sense to use named parameter notation for the first value (the
>> year)? This could be potentially confusing:

> How so? If it does named parameters, why not all?

There's no reason not to allow the year parameter to be named.  What
I think it shouldn't have is a default.  OTOH I see no good reason
not to allow the other ones to have defaults.  (We presumably want
timezone to default to the system timezone setting, but I wonder how
we should make that work --- should an empty string be treated as
meaning that?)

>> Similarly, to_timestamp() ...? Seems meaningless without at least a full
>> date and an hour.

> Agreed.

No, I think it's perfectly sane to allow month/day to default to 1
and h/m/s to zeroes.

I do think it might be a good idea to have two functions,
construct_timestamp yielding timestamptz and construct_date
yielding date (and needing only 3 args).  When you only want
a date, having to use construct_timestamp and cast will be
awkward and much more expensive than is needed (timezone
rotations aren't real cheap).

            regards, tom lane

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Analysis Function
Next
From: Magnus Hagander
Date:
Subject: Re: Analysis Function