Как добавить дату в posgresql

to_date(текст, формат)

или я что то не понял?

to_date('1946-00-00','YYYY-MM-DD') - записывает 1946-01-01

Нет в календаре такой даты, по этому ее не возможно записать.

Ааа.. у тебя вопрос по самой дате? Тут затрудняюсь сказать. А кто/что формирует такую дату? Откуда она берется? Если это реально дата, то странная на самом деле.

Может это не дата, а интервал?

Никак.

Вангую, что это извращение нужно для хранения дня рождения, если известен только возраст. Придется добавлять второе поле — например булево exact_date.

есть вот такая дата ‘1946-00-00’

Такой даты нет.

в firebird'e есть

Её в объективной реальности нет, при чём тут firebird? А то что какая-то игрушечная субд жрёт невалидные данные чести ей не делает.

в firebird’e есть

Ну квест какой то.) Ни в какой субд нет такой даты, ты не верно формируешь дату. Это же ты хочешь добавить запись в таблицу. СУБД такую фигню тебе записать не позволит.

Поменяй тип колонки на text и добавляй хоть чёрта лысого, только не называй это датой.

а что же с остальными записями делать? Да и к тому же фротенд интерфейс завязан на календаре и куча всего остального

Какая разница фронту, как у тебя в БД данные хранятся?

данные приходят в базу из календаря, а потом в обратном направлении если надо

И чо?

Покажи, кстати, в каком календаре есть нулевой день нулевого месяца.

так в том то и прикол, в базу положить 0 дату нельзя, в календарь тоже, куча арифметики дат на типе данных и все это так - не подступиться

в базу положить 0 дату нельзя, в календарь тоже

И в итоге всё нормально работает.

А Firefbird с этим как работает?

Не в курсе, случай был как-то дату по-моему впихнули. Редкий единорог 🦄

Ну здрассти, так какое поведение тебе надо-то?

Какое такое поведение?

Подожди. Ты говоришь, что

1. в БД данные приходят из календаря;
2. в календарь это значение не положить, т.к. оно невалидное.

Откуда ты тогда его берёшь вообще?

Из документа

Однажды я видел как дба добавлял даты в пострес, он взял в левую руку потгрес, в правую - средних размеров дату, а затем неуловимым движением присобачил одно к другому.

А по теме.

есть вот такая дата '1946-00-00'

Нет такой даты.

Зачем ты пытаешься невалидную дату из документа сохранить? Как эта дата должна интерпретироваться? Что ты с ней будешь дальше делать?

Надо так, интерпретировать как дату, дальше не понятно что это даст тебе

Надо так, интерпретировать как дату, дальше не понятно что это даст тебе

Даты «1946-00-00» не существует в природе, как какую конкретно дату ты собираешься её интерпретировать?

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

Из документа

Вооот. Значит, надо осмыслить, что за долб оригиналы такой документ делали, и что это означает.

Я бы первым делом посмотрел, в этих документах все даты в таком виде или только некоторые? Если все, то в БД надо просто вместо даты ввести год и не париться. Если только некоторые, то второй вопрос – что эти нули означают.

Наиболее вероятная гипотеза, которую выдвинули выше — когда известен только год, но даже год имеет ценность. В таком случае тебе преобразование совершенно адекватно предлагает 1 января. Просто в таблице рядом с датой надо ввести дополнительное поле only_year, а перед укладкой в базу проверять, нули там или нет. Если нули, помечаем, что известен только год, если нет, пишем всё. И если документ такого же формата надо будет ещё и формировать, делаем обратную операцию, если only_year выставлен в true, превращаем месяц и день на выходе в нули, чтобы отличить их от реального 1 января.

Ну или как предложили выше, вместо даты просто забульбенить (c) @Eddy_Em строковое поле. Но это перекладывание контроля целостности данных с БД на прикладной уровень и в общем случае это фу. Разобраться с проблемой всё же предпочтительнее.

Короче, предметную область надо анализировать. А так, как сформулировано в ОП – это Проблема XY в сочетании с 4.2 :)

Желаемое. В БД ты отдаёшь данные, а потом запрашиваешь данные. Что ты хочешь получитьв ответ на запрос подобной даты?

Если то же самое - храни в тексте и не мучай бабушку. Если что-то другое - что?

для интервала дат в PostgreSQL существует тип с названием interval (сюрприз).

Это был очень плохой совет: вместо того, чтобы изучить, как сделать правильно - обойтись без изучения и сделать неправильно.

..как сделать правильно..

Трудно сказать, как сделать правильно. Слишком мало исходных данных, тс как то сумбурно объясняет ситуацию. Я понял так, тс получает некий документ и отдает его в субд. СУБД плюётся на такой документ (имею ввиду дату документа). Тем не менее, тс с упорством пытается впихнуть невпихуемое.) Что бы преодолеть сопротивление субд ему предложили простой способ. Это действительно, в нашем случае очень хороший вариант. ТС должен понять, что такой документ не может участвовать в электронном документообороте и храниться в электронном виде, так как документ имеет поле даты и в этом поле должна быть информация соответствующая, ликвидная. Пусть тс сделает приведение типов.) Либо ликвидная дата, либо соответствующее поле. Дискуссия бессмысленная, что тут изучать?

Именно так.

Я бы в этой ситуации сделал бы дополнительное поле с исходными данными в текстовом формате – исходные данные, из которых уже заполнял бы поле даты со своими правилами приведения, если дата некорректна или отсутствует, для текущей даты может сделал бы NULL, может 1 января 1946 года, в зависимости от задачи. Может быть сделал бы еще отдельное числовое поле для года, если только год принципиален для каких-то выборок…

Вариантов может быть много, однако для принятия правильного решения надо знать бизнес-логику приложения.

Надо так, интерпретировать как дату

Ну интерпретируй.

to_date(‘1946-00-00’,‘YYYY-MM-DD’) - записывает 1946-01-01

Чем тебя такая интерпретация не устраивает? Если исходная «дата» обозначает просто год, то этот вариант сойдёт.

вариант сойдёт

Ага, а потом надо его не спутать с 1 января

Если предполагаются и конкретные даты, то нужно менять логику работы. Сохранять отдельно признак, полная дата, или нет. Как вариант сохранять диапазон дат. Т.е. 1946-01-01, 1946-12-31. Для полных дат диапазон будет одним днём.

С другой стороны, если тебе не нужно вычислять интервалы прямо в БД и всё такое, то сохраняй тупо в строку, как уже советовали.

А ты и не знаешь дату же, ты знаешь год и всё. Месяц и день там любые могут быть. Тебе прост не с чем путать. Я удалил коммент свой с клоунадой, но если кратко то может это нечёткая дата, когда известен лишь год и всё, такое может не надо хранить как тип дата, а просто как строку, а интерпретировать уже на уровне логики приложения. Не всегда же известна точная дата, порой знаешь просто про год и месяц, а про день нет, вот и надо как-то это выделять, ну вот видимо у тебя и выделяют это нулями.

в firebird’e есть

Это можно отнести к багу

А «чтобы потом не спутать», я выше предложил вариант, как сделать.

…И самое забавное будет, если в следующих версиях FB этот баг исправят, а все, кто его использовал как фичу, получат граблями по лбу :)

Хороший Ванга, я не сообразил, что это за хрень. А так - логично.

Да нет никакого бага. Это же ТС, ему такое вбросить, как 4.2 пальца об асфальт.

$ isql-fb

SQL> create database 'mydb.fdb';
SQL> CREATE TABLE TEST (D DATE);
SQL> INSERT INTO TEST VALUES ('2024-07-25');
SQL> INSERT INTO TEST VALUES ('2024-00-00');
Statement failed, SQLSTATE = 22018
conversion error from string "2024-00-00"

Вместо поля дата сделай три отдельных поля - year, month, day и сам с ним потом разбирайся, где там у тебя получается вторник, а где неизвестно что. Потому что у тебя это не дата, и календарные функции типа дня недели с такими датами все равно работать не будут

Не в курсе, случай был как-то дату по-моему впихнули

как-то по-моему

Не значит что я уверен на 100%

как-то дату по-моему впихнули

Я тоже впихнул, но на 100% уверен, что в sqlite.

Так может, у него и в FIrebird-е текстовое поле. Он же не колется.

Может и в DBF, я уже ничему не удивлюсь. :)

$ isql-fb

Ох Ё! … А какая версия? Я его 20+ лет уже не пользовал :)

ЗыЖ: Восстановление из бэкапа починили или всё та же лотерея? :)