On Sun, Jun 13, 2010 at 17:42, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Magnus Hagander <magnus@xxxxxxxxxxxx> writes: >> On Sun, Jun 13, 2010 at 09:38, David Jarvis <thangalin@xxxxxxxxx> 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 Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
