Roy Badami wrote:
> > "Bruce" == Bruce Momjian writes:
>
> >> You also need to make EXTRACT do the right thing.
> >>
> >> eg EXTRACT (MONTH FROM INTERVAL '1-1' YEAR TO MONTH) => 1
> >>
> >> but
> >>
> >> EXTRACT (MONTH FROM INTERVAL '13' MONTH) => 13
> >>
> "Bruce" == Bruce Momjian writes:
>> You also need to make EXTRACT do the right thing.
>>
>> eg EXTRACT (MONTH FROM INTERVAL '1-1' YEAR TO MONTH) => 1
>>
>> but
>>
>> EXTRACT (MONTH FROM INTERVAL '13' MONTH) => 13
>>
>> Ditto for day-time intervals, o
Bruce> What happens if you store '13 months' into an interval
Bruce> column that is YEAR TO MONTH? Does extract MONTH return 1
Bruce> or 13?
In standard SQL the MONTH field of INTERVAL YEAR TO MONTH can't
contain a value greater than 11. Though I don't immediately see how
yo
Roy Badami <[EMAIL PROTECTED]> writes:
> Which is where my comment about EXTRACT comes in. They can both be
> stored as 13 months, but EXTRACT (MONTH FROM ...) should return 1
> month or 13 months as appropriate. Surely this isn't a problem, you
> know the type of the interval?
EXTRACT doesn't h
Roy Badami wrote:
>
> Tom> In order to support the spec *exactly*, we would have to.
> Tom> For instance we cannot presently tell the difference between
> Tom> '13 months' and '1 year 1 month' ... they both end up stored
> Tom> as '13 months'. I can't say that I find this very imp
Tom> In order to support the spec *exactly*, we would have to.
Tom> For instance we cannot presently tell the difference between
Tom> '13 months' and '1 year 1 month' ... they both end up stored
Tom> as '13 months'. I can't say that I find this very important,
Tom> but it does
Bruce> o Interpret INTERVAL '1 year' MONTH as
I'm still not convinced that allowing this doesn't just create
unnecessary confusion. How about:
o Decide whether constructs such as INTERVAL '1 year' MONTH should
be allowed, and if so what they should mean, eg perhaps CAST
(INTERVAL
Bruce Momjian writes:
> ... I don't think we are
> going to have to change any internal representations.
In order to support the spec *exactly*, we would have to. For instance
we cannot presently tell the difference between '13 months' and '1 year
1 month' ... they both end up stored as '13 mont
Roy Badami wrote:
> Bruce> Here is an email stating it is implementation defined:
>
> Bruce>http://archives.postgresql.org/pgsql-bugs/2005-03/msg00162.php
>
> Hmm, looks like I'm mistaken, then. In fact the "whether to truncate
> or round" bit suggests you should do one or the other,
Bruce> Here is an email stating it is implementation defined:
Bruce> http://archives.postgresql.org/pgsql-bugs/2005-03/msg00162.php
Hmm, looks like I'm mistaken, then. In fact the "whether to truncate
or round" bit suggests you should do one or the other, rather than
raise an except
Roy Badami wrote:
> Bruce> Seems that is implentation-dependent so I added "round' or
> Bruce> error" to the TODO item.
>
> Ah, OK. "A guide to the SQL standard" claims it's an exception, but I
> haven't checked the actual standard.
Here is an email stating it is implementation defined:
Bruce> Seems that is implentation-dependent so I added "round' or
Bruce> error" to the TODO item.
Ah, OK. "A guide to the SQL standard" claims it's an exception, but I
haven't checked the actual standard.
Bruce> Uh, I think this already works fine for PG syntax, and I
Bruce> assu
Roy Badami wrote:
>
> Bruce> Is this sufficient?
>
> Also support for ANSI interval data types is incomplete in the parser,
> in that it doesn't recognize the precision field.
>
> eg CREATE TABLE foo (a INTERVAL MONTH(3));
>
> fails to parse.
Added to TODO:
o Support precision, C
Roy Badami wrote:
> > "Bruce" == Bruce Momjian writes:
>
> Bruce> OK, here are the TODO items I have created:
>
> Bruce> * Add support for ANSI time INTERVAL syntax, INTERVAL '1
> Bruce> 2:03:04' DAY TO SECOND
>
> Bruce> * Add support for ANSI date INTERVAL
> Bruce>
Bruce> Is this sufficient?
Also support for ANSI interval data types is incomplete in the parser,
in that it doesn't recognize the precision field.
eg CREATE TABLE foo (a INTERVAL MONTH(3));
fails to parse.
-roy
---(end of broadcast)-
> "Bruce" == Bruce Momjian writes:
Bruce> OK, here are the TODO items I have created:
Bruce> * Add support for ANSI time INTERVAL syntax, INTERVAL '1
Bruce> 2:03:04' DAY TO SECOND
Bruce> * Add support for ANSI date INTERVAL
Bruce> syntax, INTERVAL '1-2' YEAR TO MONT
Bruce Momjian writes:
> Tom Lane wrote:
>> * Add support for ANSI date INTERVAL syntax, INTERVAL '2005-3' YEAR TO MONTH
> Uh, I thought about that, but we are talking about an interval here, not
> a year, so 2005 years seems like a strange number of years to span.
Oh, right. Never mind ...
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, here are the TODO items I have created:
>
> > * Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO
> > SECOND
> > * Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
>
> That example might better read,
Bruce Momjian writes:
> OK, here are the TODO items I have created:
> * Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO
> SECOND
> * Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
That example might better read, say,
* Add support for ANSI
OK, here are the TODO items I have created:
* Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO
SECOND
* Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
* Process mixed ANSI/PG INTERVAL syntax, and round value to requested
precision
Interp
On Sat, 19 Mar 2005, Roy Badami wrote:
> Roy> I don't have a copy of the spec, but according to "A guide to
> Roy> the SQL standard" conversions like this that would discard
> Roy> data are supposed to raise an exception.
>
> Just to clarify, my understanding is that in ANSI SQL it is
Roy> I don't have a copy of the spec, but according to "A guide to
Roy> the SQL standard" conversions like this that would discard
Roy> data are supposed to raise an exception.
Just to clarify, my understanding is that in ANSI SQL it is valid to
convert from the data type INTERVAL YEAR
> "Bruce" == Bruce Momjian writes:
Bruce> First, the fundamental issue with intervals is that they
Bruce> are not tied to a particular date, meaning there is no way
Bruce> to map a specific number of days to a number of months.
Bruce> (Some days are also 23 or 25 hours but tha
Roy Badami wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1518
> Logged by: Roy Badami
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.1
> Operating system: Solaris 9
> Description:Conversions to (undocumented) SQL year-month and
24 matches
Mail list logo
