Re: proposal: simple date constructor from numeric values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Brendan Jurd <direvus(at)gmail(dot)com>
Subject: Re: proposal: simple date constructor from numeric values
Date: 2013-11-17 20:12:32
Message-ID: 16303.1384719152@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Thanks. I wasn't sure about the error message returned when times are
> outside range; how about this instead? I'm not wedded to this approach
> -- I can return to yours if this one isn't liked -- but I think the
> more specific messages are better. I realize this is inconsistent with
> the make_date case which always displays the full date instead of
> specific fields, but I think it's more likely that someone is doing
> arithmetic to enter time fields than date. (Anyway maybe this is not an
> important enough issue to create more work for translators.)

I thought that last point was the most important one: doing it like that
would create more work for translators than it's worth. There's no reason
to think that people can't figure out which field it's unhappy about.
And what if more than one field is wrong? You'd be exposing an
implementation detail about the order in which the tests are made.

Another issue with the patch as submitted was that make_date with a
negative year value behaved unreasonably. I made it throw error, but
you could also argue that say "-44" ought to mean "44 BC". (Year zero
should be disallowed in any case, of course.) It would take a few
extra lines of code to do that.

Committed with those changes and some other cosmetic adjustments.

This doesn't really finish the TODO item, as that contemplated a
make_timestamp() function as well; but I don't see a reason not
to commit what we've got.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Johnston 2013-11-17 20:45:26 Re: additional json functionality
Previous Message David E. Wheeler 2013-11-17 20:05:28 Re: CREATE TABLE IF NOT EXISTS AS