DorBer Feb 18 2008 at 13:46

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

1 min

732

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 ... ;

-1

maniac Feb 19 2008 at 11:43

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

el777 Feb 19 2008 at 12:38

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

-1

glebofff Feb 19 2008 at 18:44

Триггером.

el777 Feb 19 2008 at 19:07

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

-1

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

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

Show the best of all time