Re: BUG #1518: Conversions to (undocumented) SQL year-month

From: Roy Badami <roy(at)gnomon(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Roy Badami <roy(at)gnomon(dot)org(dot)uk>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1518: Conversions to (undocumented) SQL year-month
Date: 2005-03-23 22:56:44
Message-ID: 16961.62508.557374.862075@giles.gnomon.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

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