pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: David Jarvis <thangalin@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Analysis Function
Date: Sun, 13 Jun 2010 11:42:19 -0400
Message-ID: <14107.1276443739@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTil3RK4qbICWfbyJNJi7lxyNnFHwWlhaLmsZh3Rn@mail.gmail.com>
References: <AANLkTikihIMleazgqo1NhLo7LA5Tiujz4TIfBL1agxAp@mail.gmail.com>
	<AANLkTikZKwBCR8QfGph3aH34A2dJ2NQyOjq-Pt3eZ3_z@mail.gmail.com>
	<4C119B3E.3090608@squeakycode.net>
	<AANLkTinjUmGWmB3jsjj-6w_44c0K7f_wSrH_1TALPaOY@mail.gmail.com>
	<m34ohahrp4.fsf@passepartout.tim-landscheidt.de>
	<AANLkTik3l6uedzVJLqn-nueNva46NAFwxbpSe1XSc26_@mail.gmail.com>
	<m3typ9hl6a.fsf@passepartout.tim-landscheidt.de>
	<AANLkTikPcYh1vMxVynxGnD4RCch8-DMixiGK1v9kO17Z@mail.gmail.com>
	<AANLkTim6TrfgLiXM3sTSx6rgXQ3zNLTWBTD_MbU0OPsv@mail.gmail.com>
	<12241.1276287655@sss.pgh.pa.us>
	<AANLkTil8w33uYIadqvvecTEvTmY9aNvstpuiy1tryyT7@mail.gmail.com>
	<AANLkTinPNQZv_9BS1fkoLPXzcBZe8FFv77PBRhPR-GpL@mail.gmail.com>
	<4C14746F.9050603@enterprisedb.com>
	<AANLkTikBJ4fOqQm4A_sq68SlWnJKkjYKA2L02C4vWQwO@mail.gmail.com>
	<AANLkTil3RK4qbICWfbyJNJi7lxyNnFHwWlhaLmsZh3Rn@mail.gmail.com>

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



view thread (30+ messages)  latest in thread

Message-ID: <14107.1276443739@sss.pgh.pa.us>
Permalink:  ../14107.1276443739@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/14107.1276443739@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, magnus@hagander.net, thangalin@gmail.com, heikki.linnakangas@enterprisedb.com
  Subject: Re: Analysis Function
  In-Reply-To: <14107.1276443739@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox