XM признайтесь таки, што фсе эти преобразования типа '1 day'::interval; или, шо хуже ("mytable"."days" ||' day')::interval - ретткий ийтиотизьм. Таки фнутре ш у её хте-то неонка (цифирь, т.е.)? т.ч. преобразование к техсту - турость.

XMну их к псям...солидарен

мдя-ссс. И хто бы разъяснил, откель такая напасть с датами в постгрессе? Мохабыть она, эта жуть в ришете, какие чудеса в поиске даётть-тьть? А то ш субейсы и M$ следом за ими обычным флоатом кажисть обошлись. Ачвидна -па нидамыслию, и отсутствию сурьезных академических наработок - некому было на путь истинный ванек наставить

доходит до маразма:
SELECT 982384720 * ('1 second'::INTERVAL);
11370 days 04:38:40"
т.е. - "туда дуй"
===
SELECT 982384720 * ('1 second'::INTERVAL)/('1 second'::INTERVAL);
ERROR: operator does not exist: interval / interval
HINT: No operator matches the given name and argument type(s). You may need to add explicit type casts.
т.е. "обратно - уйй"
т.е. прямая операция определена, обратная - нон фига.


приходицца:
SELECT EXTRACT(EPOCH FROM (982384720 * ('1 second'::INTERVAL)));
982384720

зато хоття бы сам дергает ее (EPOCH) из таймштампу
SELECT EXTRACT(EPOCH FROM ('epoch'::TIMESTAMP WITH TIME ZONE+(982384720 * ('1 second'::INTERVAL))));
982384720


___________________________
ЗЫ версия про скачки времен интересна. Вот только каким боком предложенная структура спасает (а обычные флоаты не пляшут)?

LeXa NalBatВ первом случае умножаете число на интервал, а во втором делите интервал на интервал. А разделить интервал на число можно.дык если задана операция
TypA*TypB=TypC
то ничто не мешает задать 2 (две!) обратные операции
TypC/TypA = TypB
и
TypC/TypB =TypA

т.е. "ниппель" имеет место быть - одна из обратных операций не определена (што не имеет в данном случае нормальных оснований).

_______
т.ч. ваших соображений, почему интервал на интервал делить низзя - в упор не вижу. Размерность - одинакая (время), типы счислимые. Физиццки не запрещено часы делить на годы или века и получать числа. Правда могут быть возражения для лет - по длительности "физичесого" vs "календарного" года (високосность там и т.п.), опять таки скорость вращения (длительность дня/года) меняецца но тем не менее.

LeXa NalBat Вроде бы это не верно. К примеру, линейное пространство X. Определена операция y = a * x, где x, y C X, a C R. Легко определить оперцию y = x / a, через y = b * x, где b = 1/a C R. Но операции y / x, результатом которой было бы действительное число, нет.
[/quote]если деление на 0 неопределено, мы же не утверждаем что и деление на мн-ве целых (и т.п.) чисел не определено. Т.ч. если ветора некоего лин. пр-ва. коллинеарны, то и деление для них определено, а если нет - "переполнение" (Null или иное). (т.е. деление определено, пусть не "всюду", даже на таких "разнородных" объектах, как вектора.

"Вектора" же "интервалов" не являются независимыми. Вся проблема в смешивании в них релятивных (год, месяц) и абсолютных компонент (день, час, минута). Ктати, очень интересно посмотреть как сравниваются релятивные части (понятно, что год<>год (если сранивать "в абсолютных смыслах"), а вот в постгресе год=год. А далее со сравнениями ваапще бардак.

если кто-то мне объяснит методы сравнения интервалов и рез-ты b,c,h3,j и k, то "велкам". Пока же я думаю, что надобно застрелить разработчиков временных типов в постгреса из духового ружжа. Шоб не мучились. Ибо нех.


кстати сказать без некоего розмысла неочевидно, будет ли результатом вычитания двух тайштампов интервал "в абсолютных" единицах, или "смешанного типа"?

[quot LeXa NalBat]Соображений о невозможности деления интервала на интервал у меня нет. Есть только предположения, из-за чего это не реализовано - а) в силу (неизвестной мне:) некой непреодолимой логической трудности это невозможно, б) в силу технической трудности это относительно трудно реализуемо, поэтому пока не сделано (например, учитывать сдвиги времени (для каждой локали разные) проще (для программистов postgres) работая со структурой pg_tm, а не с числом, поэтому выбран этот тип, но реализовать деление таких структур труднее, чем чисел), в) это почти никому не нужно, поэтому не сделано. Если попытаться угадать, я бы предположил, что причина - случай б).аппсплютно очивидно, шо релятивные части должны делицца на релятивные, аппсолютные -на аппсолютные, неколиннеарность "интервалов" возвращает неопределенность. Видимо нереализованно именно в силу смешанного релятивно/аппсолютного смысла интервала. (т.е. интервал это не время, а смесь относительных едениц и абсолютных, взятая в произвольном соотношении). Поэтому поддерживать на них большинство операций бессмысленно (возврат по большей части будет неопределен)

Странно, что для интервала определено сравнение. При наличии _ненулевых_ частей в относительной части сравнение должно производиться с некоторым лагом например:

год=год должно возвращать Null !!!
(или хотя бы (год= 365 дней)==Null)
как и
(месяц = месяц) == Null
но
(год+2 дня)>год =True
месяц >= месяц + 3дня

___
вот просветите меня, есь ли аппсолютные временные и интервальные типы в постгресе? (с определенными на них функциями, в том числе операциями с относительными временными понятиями).

LeXa NalBat Вроде бы это не верно. К примеру, линейное пространство X. Определена операция y = a * x, где x, y C X, a C R. Легко определить оперцию y = x / a, через y = b * x, где b = 1/a C R. Но операции y / x, результатом которой было бы действительное число, нет.
если деление на 0 неопределено, мы же не утверждаем что и деление на мн-ве целых (и т.п.) чисел не определено. Т.ч. если ветора некоего лин. пр-ва. коллинеарны, то и деление для них определено, а если нет - "переполнение" (Null или иное). (т.е. деление определено, пусть не "всюду", даже на таких "разнородных" объектах, как вектора.

"Вектора" же "интервалов" не являются независимыми. Вся проблема в смешивании в них релятивных (год, месяц) и абсолютных компонент (день, час, минута). Ктати, очень интересно посмотреть как сравниваются релятивные части (понятно, что год<>год (если сранивать "в абсолютных смыслах"), а вот в постгресе год=год. А далее со сравнениями ваапще бардак.

если кто-то мне объяснит методы сравнения интервалов и рез-ты b,c,h3,j и k, то "велкам". Пока же я думаю, что надобно застрелить разработчиков временных типов в постгреса из духового ружжа. Шоб не мучились. Ибо нех.


кстати сказать без некоего розмысла неочевидно, будет ли результатом вычитания двух тайштампов интервал "в абсолютных" единицах, или "смешанного типа"?

LeXa NalBatСоображений о невозможности деления интервала на интервал у меня нет. Есть только предположения, из-за чего это не реализовано - а) в силу (неизвестной мне:) некой непреодолимой логической трудности это невозможно, б) в силу технической трудности это относительно трудно реализуемо, поэтому пока не сделано (например, учитывать сдвиги времени (для каждой локали разные) проще (для программистов postgres) работая со структурой pg_tm, а не с числом, поэтому выбран этот тип, но реализовать деление таких структур труднее, чем чисел), в) это почти никому не нужно, поэтому не сделано. Если попытаться угадать, я бы предположил, что причина - случай б).аппсплютно очивидно, шо релятивные части должны делицца на релятивные, аппсолютные -на аппсолютные, неколиннеарность "интервалов" возвращает неопределенность. Видимо нереализованно именно в силу смешанного релятивно/аппсолютного смысла интервала. (т.е. интервал это не время, а смесь относительных едениц и абсолютных, взятая в произвольном соотношении). Поэтому поддерживать на них большинство операций бессмысленно (возврат по большей части будет неопределен)

Странно, что для интервала определено сравнение. При наличии _ненулевых_ частей в относительной части сравнение должно производиться с некоторым лагом например:

год=год должно возвращать Null !!!
(или хотя бы (год= 365 дней)==Null)
как и
(месяц = месяц) == Null
но
(год+2 дня)>год =True
месяц >= месяц + 3дня

___
вот просветите меня, есь ли аппсолютные временные и интервальные типы в постгресе? (с определенными на них функциями, в том числе операциями с относительными временными понятиями).

кстати вот думаю, что и операции на них не подчиняюца перестановочным законам. Прибавить месяц,а потом 30 дней или прибавить 30 дней, а потом месяц - разные вестчи. Т.ч. сравнение для интервалов таки столь же неопределенная вещь, как и деление. (разве что "область определенности" поширше, а область неопределенности - поуже)

т.е. пафос-то фсей бодяги ф томм, шо разница двух дат-времен есь величина аппсолютная, и должна выражацца в аппсолютных временных типах, а приводицца к смешанному типу токо по требованию. (ибо результат приведения зависит как от точки старта так и от пропорции разложения по аппсолютным и относительным составляющим). А вот для искомого аппсолютного временного типа сложение, умножения и деление _обязаны_ быть определены. А академические изыски - стронго фсад их аффтарам .

поправочка. Фместа Null для сравнения интервалов разработчикам предлагается ввести (куда-нть) несовсем определенный результат возврата ItDepends

XMполучается муйня.
...
P.S. "Все врут календари" (c)
аптом и ретчь.
Т.е. операции сравнения интервалов надо свершать оченно аккуратно, не забывая што это вестчи смешанные релятивно-аппсолютные. и сравнение для них в постгресе построенно в корне неверно. Радует только, что разница таймштампофф хотя и являецца интервалом, но таки, кажецца, интервалом исключительно в аппсолютных единицах:

SELECT '2013-01-01'::timestamp - '2000-01-01'::timestamp;
"4749 days"
(тип возврата interval)

vs
SELECT INTERVAL '12 year' + INTERVAL '365 day'
"12 years 365 days"
(тип возврата interval)

Т.е. для дельт таймштампов сравнение похоже должно быть пральным.

XM SQL 1999 ....Year-month intervals...
немного думал. резюме такое:

интервальный тип должен обеспечивать сложение интервалов, но поскольку "месяц + 30 дней"<>"30 дней+месяц", то и интервалы эти разные. сталобыть интервал должен не только копить абсолютные и относительные "интервалы", но и порядок их следования. Свертка соседей (по порядку) допустима только для однотипных "элементалей" (Есть вырожденный случай, когда в неком участке массива набирается строго кратное 400 годам количество лет относительными интервальными типами "год" и "месяц" - тогда этот кусок массива можно свернуть до 2-х елементов в произвольном порядке). Т.е. интервал это "строка" или массив переменной длинны с элементами "чистых" типов. Суммирование и вычитание == дописывание вторго слагаемого (массива) в конец первого. Возможно со сверткой однотипных соседей. Предполагаемая структура элемента массива (value,typeOf) (можно вводить и месяца/годы других календарей). Как-то так. Интервальный тип же постгреса попросту вреден (см. сравнение, сложение и т.п.).

LeXa NalBat 4321интервальный тип должен обеспечивать сложение интервалов, но поскольку "месяц + 30 дней"<>"30 дней+месяц"Этого не наблюдается.

select interval '1 year' + interval '400 days', interval '400 days' + interval '1 year';
?column? | ?column?
-----------------+-----------------
1 year 400 days | 1 year 400 days неприятно удивлен.
читать надо таки то, что вам пишут, а не то, что вы хотите:
4321кстати вот думаю, что и операции на них не подчиняюца перестановочным законам. Прибавить месяц,а потом 30 дней или прибавить 30 дней, а потом месяц - разные вестчи. таким образом "это наблюдается" в "действительности" , но не наблюдаецца (как вы правильно заметили, а вам об этом и пытаются сообщить, чего вы не заметили) в постгрессовском способе работы с "интервалами" , который, таким образом, "фкорне" неверен. (не отражает положение дел с интервалами ф дефствителности)

а ваш результат на 1 месяце и 30 днях я вам уже получал и выше.
Или вы считаете, что
дата + 1 месяц + 30 дн = дата + 30 дн + 1 месяц
?
а дату такую не подскажете?

__________
и мне фсе равно, почему продухт неправильно работает, ежели я знаю, что идеология его к иному не приспособлена. (сравнение смешанных интервалов в постгре)

еще раз, "релятивные" интервалы - это функционалы, результат действия которых зависит от текущей даты к которой они плюсуюцца (т.е. от места в сногоместной сумме). Поэтому сравнить 2 "одинаковых" функционала нельзя. И перемещать функционалы в цепочке сложений тоже нельзя. Необходимо соблюдать заданный порядок. (Если на дату падает некий поток "воздействий" - добавляются и плюсуюца как абсолютные интервалы, так и месяцы, то результат зависит от порядка воздействий, таким образом просто накопить "в независимой", векторной структуре (как в посгре) оттдельно абсолютные, отдельно относительные воздействия и подействовать накопленными пачками на дату в том или ином порядке (сначала относительно, потом абсолютно или наоборот) просто нельзя. Так же нельзя сравнивать функционалы (месяцы и годы, лучше всего еврейского или иного подобного календаря, но сойдет и почти равномерный стандартный) в смысле сравнения "абсолютных" интервалов. А если сравнивать именно в таком, абсолютном смысле, придется вводить результат возврата ItDepends.