Главное отличие версии 8.3, которое может вызвать проблемы при переходе на нее

[kronos]

А почему просто не поставили постгрес помладше?

[DorBer]

:) А смысл? Специально с новым сервером новое ПО ставили.

[kronos]

Ну что значит смысл :) Чтобы не делать костылей типа креат каст )

[DorBer]

В новых версиях, я так понимаю, ситуация не изменится. Так что лучше раньше, чем позже. Тем более большинство запросов уже переписано, «касты» я снес, полет нормальный :)

[dewil]

согласен.
лучше адаптировать код.

[glebofff]

В SQL Server'e, DB2, да и наверняка во многих СУБД также имеется "несовместимость" (запрет на implicit cast/conversion) типов данных между собой.

Всегда ли сервер знает, чего конкретно мы хотим от него добиться? Можно ли доверять всем результатам неявного приведения типов? В MySQL, например, datetime можно сравнивать с чем угодно, и засунуть туда что угодно - хоть '0000-00-00 00:00:00'. А что, нулевая дата. Вполне себе. И при этом не-NULL. :-)

[DorBer]

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

[ld100]

Вряд-ли, MySQL слишком любим быдлокодерами и шаред хостингами, которые просто перестанет апгрейдить MySQL... А может, просто, добавят какой-нибудь ключ в конфиг для переключения старого и нового режима.

[DorBer]

MySQL любим не только быдлокодерами, но и Гуглом :) Начиная с 5-ой версии они очень хорошо подтянулись по функционалу. Я удивлен, что у постгри такого ключа в конфиге нету...

[ld100]

А я и не говорил что только быдлокодерами :) Просто быдлокодеры не знают что бывает что-то еще :)

[WoZ]

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

[nanotime]

ну он, типа, не быдлокодер, мусклем поэтому не пользуеццо)

[el777]

Быдлокодеры? Ну-ну...
Если Вы не в курсе, MySQL очень сильно подтянулся по функционалу с версии 3.23.
Сейчас там есть очень полезные функции, которых нет в постгре.
Причем не какая-то лабуда, а очень серьезные и удобные в первую очередь в больших системах с репликациями и синхронизациями, а не на домашней страничке Пупкина.

Чтобы не быть голословным: атомарный запрос на вставку или обновление
INSERT ... ON DUPLICATE KEY UPDATE ... ;

[maniac]

да, я влюблен в эту конструкцию.

[el777]

Его сильно не хватает в более сильных базах.
Чем ответит PostgreSQL на этот вызов?

[glebofff]

Триггером.

[el777]

То есть опять приходится огород городить....
Мне попадались довольно муторные реализации этого с триггером, функцией .
Вы знаете какой-нибудь столь же простой и элегантный вариант как приведенный запрос?

[glebofff]

Этот простой и элегантный вариант не имеет никакого отношения к стандартам.

[el777]

Зато работает :)
Этих стандартов существует столько же сколько и СУБД. Каждый разработчик думает, что вот именно этой супер фичи не хватает всем остальным и добавляет себе :)

[glebofff]

Триггер тоже работает.

[el777]

Вы про вот этот кошмар?
http://www.postgresql.org/docs/current/s…

[glebofff]

Нет, не про этот, хотя технологии используются те же (found, или get diagnostics, etc). :-) Расписал было, но потом стёр, вам это один хрен неинтересно. :-)

[el777]

Да нет, мне как раз интересно, иначе бы не писал среди ночи ;-) Чисто практический интерес - на мускуле я такую вещь использовал, что хорошо помогло.
А вот как теперь сделать аналогичное в более сложном проекте на Postgre - приходится ломать голову. И ведь что обидно: база дает богатые более сложные возможности, а вот такой на первый взгляд простой вещи - нет.
Если не секретно, то поделитесь :)

[samokhvalov]

Есть стандартный (ISO/ANSI SQL) подход:
INSERT INTO ... SELECT ... WHERE NOT EXISTS

[samokhvalov]

ну там на слове EXISTS, конечно, предложение не заканчивается :-)

... NOT EXISTS (...)

Многоточия предлагаю заполнить читателю, в соответствии с конкретной ситуацией. Это несложно

[samokhvalov]

Прошу прощения, я описал совсем другое. INSERTorUPDATE действительно, триггером делается. Я же описал «INSERT без ругательств».

[el777]

как именно не подскажете?

[samokhvalov]

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

Это один из вариантов.

[el777]

А как быть с атомарностью? Или придется лочить таблицу?

[samokhvalov]

см мой ответ самому себе :-)

[el777]

В принципе да, мне такой вариант тоже больше нравится. Но все равно вопросы надежности остаются.
Вот смотрю как здесь http://www.digipedia.pl/pgsql/81/plpgsql… народ перестраховывается: вначале UPDATE, если строку не обнаружили, то делаем INSERT, а если вдруг кто-то еще вставляет эту строку, то перехватываем EXCEPTION и снова делаем UPDATE.
Жесть! :)

[samokhvalov]

Конечно, такой вариант тоже не фонтан в условиях высокой нагрузки и READ COMMITED. Можно наоборот — делать INSERT, потом ловить ошибку нарушения целостности по UK: что-то вроде BEGIN .. INSERT .. EXCEPTION WHEN unique_violation THEN .. UPDATE .. END;

при таком подходе конкурируют UPDATE-ы, что более приятно.

[el777]

ох и дюже сложная конструкция :)
а самое главное - не атомарная - http://archives.postgresql.org/pgsql-bug…
то есть чреватая проблемами при нагрузке.
Может конечно что-то за 6 лет изменилось...

[WoZ]

ld100 решил повы@бываться... было бы чем только)

[realfreeman]

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

[ld100]

В новых версиях, вообще-то, кроме новых фич есть исправления недоработок старых версий.
А в том же PHP5 делали режим совместимости с PHP4.

[DorBer]

Не настолько большая разница между 4-ым и 5-ым PHP, чтобы сильно запариться оставляя совместимость :)

[bio]

Зачем же спешить с перездом, проще же сначала почитать Release Notes. Подробно расписаны все грабли :)

"Non-character data types are no longer automatically cast to TEXT (Peter, Tom)"

[DorBer]

Сервер готовил не я, софт ставил не я. Я пришел, когда уже было поздно :)
Но все же, думаю, оно к лучшему :)

[AlienZzzz]

Такая же проблема была(только переход был с Мускула (212к записей), размер таблиц около 600 метров) на 8.3.
1. Я вытыщил все данные(дампом с CVS)
2. открыл в хексовом редакторе (пользовался BLESS, так как просто какой под рукой был тот и взял)
3. заменил по регекспу все 0x00 (все что не правильное, благо все поля были текстовые) на пробелы
4. коммандой COPY загнал в таблицы для импорта (причем специально создал еще tablespace под индексы и под сами таблицы)
5. на пхп обработал все записи (не надо смеятся, там сложно(например из "Форд запчасти", необходимо получить ford_zapchasti", да еще и проверить нет ли дубликатов, а если есть взять от этого дубликата ID и работать уже с ним, если нет, то добавить новую запись) было а PG/SQL я не так хорошо знаю.
6. Все
___
Работа заняла 2 часа на все (долго вытаскивал из мускула, так как у провайдера стояли ограничения и приходилось 212к записей брать по 10к ( )

[AlienZzzz]

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