| 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
| 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 |