From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | David Jarvis <thangalin(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Analysis Function |
Date: | 2010-06-13 15:42:19 |
Message-ID: | 14107.1276443739@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sun, Jun 13, 2010 at 09:38, David Jarvis <thangalin(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-06-13 15:49:50 | Re: Analysis Function |
Previous Message | Tom Lane | 2010-06-13 15:34:20 | Re: Analysis Function |