Re: BUG #1518: Conversions to (undocumented) SQL year-month and
От | Roy Badami |
---|---|
Тема | Re: BUG #1518: Conversions to (undocumented) SQL year-month and |
Дата | |
Msg-id | 16961.51696.587154.430725@giles.gnomon.org.uk обсуждение исходный текст |
Ответ на | Re: BUG #1518: Conversions to (undocumented) SQL year-month and (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: BUG #1518: Conversions to (undocumented) SQL year-month and
|
Список | pgsql-bugs |
>>>>> "Bruce" == Bruce Momjian <pgman@candle.pha.pa.us> 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 MONTH You may as well use the correct ANSI terminology: * Add support for ANSI day-time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO SECOND * Add support for ANSI year-month INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH Bruce> * Process mixed ANSI/PG INTERVAL syntax, and round value Bruce> to requested precision Never round, I think. Throwing away precision should be an exception, unless the discarded fields were zero. Bruce> Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 Bruce> year' AS INTERVAL MONTH), and this should return '12 Bruce> months' Bruce> Is this sufficient? 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, of course. I'll have a think about if there's anything else... -roy
В списке pgsql-bugs по дате отправления: