DorBer Feb 18 2008 at 13:46

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

1 min

786

PostgreSQL*

+20

Comments 41

kronos Feb 18 2008 at 13:55

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

DorBer Feb 18 2008 at 13:56

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

kronos Feb 18 2008 at 14:14

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

DorBer Feb 18 2008 at 14:22

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

dewil Feb 18 2008 at 14:34

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

glebofff Feb 18 2008 at 14:44

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

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

DorBer Feb 18 2008 at 15:04

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

ld100 Feb 18 2008 at 18:34

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

DorBer Feb 18 2008 at 18:50

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

ld100 Feb 18 2008 at 21:37

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

WoZ Feb 19 2008 at 11:01

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

nanotime Feb 19 2008 at 18:41

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

el777 Feb 19 2008 at 11:37

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

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

maniac Feb 19 2008 at 11:43

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

el777 Feb 19 2008 at 12:38

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

glebofff Feb 19 2008 at 18:44

Триггером.

el777 Feb 19 2008 at 19:07

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

glebofff Feb 19 2008 at 20:41

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

el777 Feb 19 2008 at 21:18

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

glebofff Feb 19 2008 at 21:43

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

el777 Feb 19 2008 at 22:25

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

glebofff Feb 19 2008 at 23:03

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

el777 Feb 19 2008 at 23:15

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

samokhvalov Feb 20 2008 at 21:28

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

samokhvalov Feb 20 2008 at 21:29

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

... NOT EXISTS (...)

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

samokhvalov Feb 20 2008 at 21:40

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

el777 Feb 21 2008 at 00:28

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

samokhvalov Feb 21 2008 at 11:54

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

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

el777 Feb 21 2008 at 12:07

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

samokhvalov Feb 21 2008 at 12:16

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

el777 Feb 21 2008 at 12:42

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

samokhvalov Feb 21 2008 at 12:16

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

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

el777 Feb 21 2008 at 00:27

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

WoZ Feb 19 2008 at 18:57

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

realfreeman Feb 18 2008 at 20:12

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

ld100 Feb 19 2008 at 10:00

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

DorBer Feb 19 2008 at 10:26

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

bio Feb 19 2008 at 01:20

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

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

DorBer Feb 19 2008 at 02:01

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

AlienZzzz May 27 2008 at 09:21

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

AlienZzzz May 27 2008 at 10:00

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