Открыть список
Как стать автором
Обновить

Комментарии 41

А почему просто не поставили постгрес помладше?
:) А смысл? Специально с новым сервером новое ПО ставили.
Ну что значит смысл :) Чтобы не делать костылей типа креат каст )
В новых версиях, я так понимаю, ситуация не изменится. Так что лучше раньше, чем позже. Тем более большинство запросов уже переписано, «касты» я снес, полет нормальный :)
согласен.
лучше адаптировать код.
В SQL Server'e, DB2, да и наверняка во многих СУБД также имеется "несовместимость" (запрет на implicit cast/conversion) типов данных между собой.

Всегда ли сервер знает, чего конкретно мы хотим от него добиться? Можно ли доверять всем результатам неявного приведения типов? В MySQL, например, datetime можно сравнивать с чем угодно, и засунуть туда что угодно - хоть '0000-00-00 00:00:00'. А что, нулевая дата. Вполне себе. И при этом не-NULL. :-)
Правильно, в MySQL внутри дата хранится в собственном формате, поэтому и проблем нету. Переживаю, что насмотревшись на остальных со временем они тоже могут запретить автопреобразование в целях повышения производительности.
Вряд-ли, MySQL слишком любим быдлокодерами и шаред хостингами, которые просто перестанет апгрейдить MySQL... А может, просто, добавят какой-нибудь ключ в конфиг для переключения старого и нового режима.
MySQL любим не только быдлокодерами, но и Гуглом :) Начиная с 5-ой версии они очень хорошо подтянулись по функционалу. Я удивлен, что у постгри такого ключа в конфиге нету...
А я и не говорил что только быдлокодерами :) Просто быдлокодеры не знают что бывает что-то еще :)
зря так. быдлокодеры... даже гуру мира сего не позволяют себе такого.
ну он, типа, не быдлокодер, мусклем поэтому не пользуеццо)
Быдлокодеры? Ну-ну...
Если Вы не в курсе, MySQL очень сильно подтянулся по функционалу с версии 3.23.
Сейчас там есть очень полезные функции, которых нет в постгре.
Причем не какая-то лабуда, а очень серьезные и удобные в первую очередь в больших системах с репликациями и синхронизациями, а не на домашней страничке Пупкина.

Чтобы не быть голословным: атомарный запрос на вставку или обновление
INSERT ... ON DUPLICATE KEY UPDATE ... ;
да, я влюблен в эту конструкцию.
Его сильно не хватает в более сильных базах.
Чем ответит PostgreSQL на этот вызов?
То есть опять приходится огород городить....
Мне попадались довольно муторные реализации этого с триггером, функцией .
Вы знаете какой-нибудь столь же простой и элегантный вариант как приведенный запрос?
Этот простой и элегантный вариант не имеет никакого отношения к стандартам.
Зато работает :)
Этих стандартов существует столько же сколько и СУБД. Каждый разработчик думает, что вот именно этой супер фичи не хватает всем остальным и добавляет себе :)
Триггер тоже работает.
Нет, не про этот, хотя технологии используются те же (found, или get diagnostics, etc). :-) Расписал было, но потом стёр, вам это один хрен неинтересно. :-)
Да нет, мне как раз интересно, иначе бы не писал среди ночи ;-) Чисто практический интерес - на мускуле я такую вещь использовал, что хорошо помогло.
А вот как теперь сделать аналогичное в более сложном проекте на Postgre - приходится ломать голову. И ведь что обидно: база дает богатые более сложные возможности, а вот такой на первый взгляд простой вещи - нет.
Если не секретно, то поделитесь :)
Есть стандартный (ISO/ANSI SQL) подход:
INSERT INTO ... SELECT ... WHERE NOT EXISTS
ну там на слове EXISTS, конечно, предложение не заканчивается :-)

... NOT EXISTS (...)

Многоточия предлагаю заполнить читателю, в соответствии с конкретной ситуацией. Это несложно
Прошу прощения, я описал совсем другое. INSERTorUPDATE действительно, триггером делается. Я же описал «INSERT без ругательств».
как именно не подскажете?
Ну например, в триггерной функции можно попробовать делать сразу UPDATE и потом отловить исключение, при котором осуществлять вставку (IF NOT FOUND THEN ... INSERT ...)

Это один из вариантов.
А как быть с атомарностью? Или придется лочить таблицу?
см мой ответ самому себе :-)
В принципе да, мне такой вариант тоже больше нравится. Но все равно вопросы надежности остаются.
Вот смотрю как здесь http://www.digipedia.pl/pgsql/81/plpgsql… народ перестраховывается: вначале UPDATE, если строку не обнаружили, то делаем INSERT, а если вдруг кто-то еще вставляет эту строку, то перехватываем EXCEPTION и снова делаем UPDATE.
Жесть! :)
Конечно, такой вариант тоже не фонтан в условиях высокой нагрузки и READ COMMITED. Можно наоборот — делать INSERT, потом ловить ошибку нарушения целостности по UK: что-то вроде BEGIN .. INSERT .. EXCEPTION WHEN unique_violation THEN .. UPDATE .. END;

при таком подходе конкурируют UPDATE-ы, что более приятно.
ох и дюже сложная конструкция :)
а самое главное - не атомарная - http://archives.postgresql.org/pgsql-bug…
то есть чреватая проблемами при нагрузке.
Может конечно что-то за 6 лет изменилось...
ld100 решил повы@бываться... было бы чем только)
А если бы он был, смысл тогда переходить на новую версию?
Новые версии как раз пишутся не для поддержки старых версий, а для продвижения новых фич, которые и позволяют добиваться увеличения производительности.
В новых версиях, вообще-то, кроме новых фич есть исправления недоработок старых версий.
А в том же PHP5 делали режим совместимости с PHP4.
Не настолько большая разница между 4-ым и 5-ым PHP, чтобы сильно запариться оставляя совместимость :)
Зачем же спешить с перездом, проще же сначала почитать Release Notes. Подробно расписаны все грабли :)

"Non-character data types are no longer automatically cast to TEXT (Peter, Tom)"
Сервер готовил не я, софт ставил не я. Я пришел, когда уже было поздно :)
Но все же, думаю, оно к лучшему :)
Такая же проблема была(только переход был с Мускула (212к записей), размер таблиц около 600 метров) на 8.3.
1. Я вытыщил все данные(дампом с CVS)
2. открыл в хексовом редакторе (пользовался BLESS, так как просто какой под рукой был тот и взял)
3. заменил по регекспу все 0x00 (все что не правильное, благо все поля были текстовые) на пробелы
4. коммандой COPY загнал в таблицы для импорта (причем специально создал еще tablespace под индексы и под сами таблицы)
5. на пхп обработал все записи (не надо смеятся, там сложно(например из "Форд запчасти", необходимо получить ford_zapchasti", да еще и проверить нет ли дубликатов, а если есть взять от этого дубликата ID и работать уже с ним, если нет, то добавить новую запись) было а PG/SQL я не так хорошо знаю.
6. Все
___
Работа заняла 2 часа на все (долго вытаскивал из мускула, так как у провайдера стояли ограничения и приходилось 212к записей брать по 10к ( )
Только столкнулся с проблемой создания индекса на большых колонках, так как при создании индекса посгре говорила, что ей место не хватает для индекса, победить не смог. создал полнотексовый.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.