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

Поиск
Список
Период
Сортировка
От Roy Badami
Тема Re: BUG #1518: Conversions to (undocumented) SQL year-month
Дата
Msg-id 16961.62508.557374.862075@giles.gnomon.org.uk
обсуждение исходный текст
Ответ на Re: BUG #1518: Conversions to (undocumented) SQL year-month and  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #1518: Conversions to (undocumented) SQL year-month  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: BUG #1518: Conversions to (undocumented) SQL year-month and  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Roy Badami
Дата:
Сообщение: Re: BUG #1518: Conversions to (undocumented) SQL year-month and
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #1517: SQL interval syntax is accepted by the parser,