From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
Cc: | Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: INTERVAL data type and libpq - what format? |
Date: | 2009-05-24 20:41:19 |
Message-ID: | 10960.1243197679@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> Sam Mason wrote:
>> You get an error because " 123 11" isn't a valid literal of an
>> (undecorated) INTERVAL type.
> Hmm..... should it be?
Well, we do allow it if it's *explicitly* stated to be a day to hour
interval:
regression=# select interval '123 11' day to hour;
interval
-------------------
123 days 11:00:00
(1 row)
What's at issue here is what should happen without that context.
I'm inclined to think this is ambiguous enough that accepting it
silently isn't such a great idea. I'm also not convinced that the
SQL spec says we must --- the syntax for <interval literal> does
not appear to allow omitting the fields specification.
In a related example,
regression=# select interval '123 11' day;
interval
----------
134 days
(1 row)
we seem to be adding the 123 and 11 together. This is, um,
surprising behavior ... I'd be inclined to think throwing an
error is more appropriate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | marco santillan | 2009-05-25 02:56:10 | Query |
Previous Message | Tom Lane | 2009-05-24 18:44:52 | Re: question about SSIS |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-05-24 20:58:08 | Re: pg_class and enum types |
Previous Message | Gevik Babakhani | 2009-05-24 20:37:29 | pg_class and enum types |