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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andrew - Supernews
Дата:
Сообщение: Re: BUG #1552: massive performance hit between 7.4 and 8.0.1
Следующее
От: Roy Badami
Дата:
Сообщение: Re: BUG #1517: SQL interval syntax is accepted by the parser,