Skip site navigation (1) Skip section navigation (2)

Re: Analysis Function

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:49:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Sun, Jun 13, 2010 at 17:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?)

Umm. NULL could be made to mean that, or we could provicde two
different versions - one that takes TZ and one that doesn't.

>>> 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).

And a third, construct_time(), no?

 Magnus Hagander

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2010-06-13 15:58:24
Subject: Re: Analysis Function
Previous:From: Tom LaneDate: 2010-06-13 15:42:19
Subject: Re: Analysis Function

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group