Re: BUG #1518: Conversions to (undocumented) SQL year-month - Mailing list pgsql-bugs

From Roy Badami
Subject Re: BUG #1518: Conversions to (undocumented) SQL year-month
Date
Msg-id 16961.62508.557374.862075@giles.gnomon.org.uk
Whole thread Raw
In response to Re: BUG #1518: Conversions to (undocumented) SQL year-month and  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #1518: Conversions to (undocumented) SQL year-month  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: BUG #1518: Conversions to (undocumented) SQL year-month and  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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 put limits on how exactly we can emulate the
    Tom> spec.

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?

So you _can_ emulate the spec, you just don't use the same internal
representation that a naive implementation of the spec would...

           -roy

pgsql-bugs by date:

Previous
From: Roy Badami
Date:
Subject: Re: BUG #1518: Conversions to (undocumented) SQL year-month and
Next
From: Tom Lane
Date:
Subject: Re: BUG #1517: SQL interval syntax is accepted by the parser,