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

From Roy Badami
Subject Re: BUG #1518: Conversions to (undocumented) SQL year-month and
Date
Msg-id 16961.51696.587154.430725@giles.gnomon.org.uk
Whole thread Raw
In response to Re: BUG #1518: Conversions to (undocumented) SQL year-month and  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: BUG #1518: Conversions to (undocumented) SQL year-month and  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Andrew - Supernews
Date:
Subject: Re: BUG #1552: massive performance hit between 7.4 and 8.0.1
Next
From: Roy Badami
Date:
Subject: Re: BUG #1517: SQL interval syntax is accepted by the parser,