LINUX.ORG.RU

PostgreSQL 7.1


0

0

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

★★★★★

Проверено:

WOW :-))) Читать changelog oдно удовольствие :-)) Из наболевшего - пофиксили обработку NULLs наконец в функциях и сделали UNION в подзапросах :)) Из приятных сюрпризов - WAL и подзапросы во FROM 8-))

anonymous
()

Вот бы еще со стабильностью разобрались под нагрузкой и сделали Win32 порт - вообще бы незаменимая весч была. А то MySQL как то и реляционной БД называть неудобно. Потому как FOREIGN KEY не поддерживается, а следовательно реляций и ссылочной целостности быть не может там никакой. Хуже Access.

Bluesman

anonymous
()

Либо я криворукий, либо они рпм-ки собрали без поддержки локали. srpm тоже не собирается :((( Будем искать...

gdenis
()

А чем сырцы плохи? Всегда с нуля собираю.... До 7.1 версии она без патча на альфе не шла, счас вроде его в дистриб наконец-то запихали:)

anonymous
()

Народ, а кто может сказать, как у PostgreSQL сейчас со стабильностью?
Раньше, насколько я помню maxcom говорил, что падал он часто на www.linux.org.ru. :-)
Только, pls, аргументированное мнение.

anonymous
()

Делал я на Postgres (где-то год назад) биллинг в одной мелкой провайдерской фирме. Нареканий не было. Kraw

anonymous
()

В прошлом году мы на ней начали делать проект e-commerce ... пока работает (без претензий к СУБД) ... Стабильность (в прямых руках) отличная. Если же делать навороты, то придется и о стабильности побольше думать ... Если навороты не нужны, то стабильность будет по умолчанию - то есть отличная. В общем отличная СУБД. P.S. Это не реклама, я действительно очень доволен этой СУБД.

saper ★★★★★
()

7.0 очень стабильный релиз, реально он у меня на моей прошлой работе проработал под реальной постоянной нагрузкой примерно полгода и сейчас работает без проблем. Главное чтоб памяти достаточно было, ибо при ее окончании db corruption обеспечен. Вот 6-ка глюкавая была и любила падать без повода.

maxcom ★★★★★
() автор топика

Люди, а в она в принципе может иметь дело с таблицами с русскими названиями? - вроде и компилил с локалью, а русские названия непонимает никак(((

anonymous
()
Ответ на: комментарий от anonymous

может и без проблем: address=# create table абвгd2 ( столбец1 text); CREATE Lru

anonymous
()

Русские точно понимает, единственное если не хочет напиши русские буквы в обычных кавычках (вместе с пробелами).

Пример: create table "продукция";

saper ★★★★★
()

Народ, а такой вопрос: как по части auto_increment ? В MySQL оно как бы беспроблемно решаемо а в Postgres-e ? Реально как то сделать авто-инкремент без особых извращений ?

jeka
()

ИМХО, инкремент в MySql - изврат. В Постгресе есть sequence, с которой решается куча проблем. RTFM, короче.

Eldhenn
()
Ответ на: комментарий от jeka

В contrib'ах к PostgreSQL есть конвертор думп-файлов MySQL,
заменяющий, в том числе, auto_increment на последовательности (SEQUENCE),
что сильно облегчает переход на PostgreSQL.

Lru

anonymous
()

CREATE SEQUENCE sq / .. DEFAULT nextval('sq') спасет отца русской демократии :)

anonymous
()

Rules! Наконец-то Large-Object'ы не засерают каталог базы, а храняться в одной таблице. И файловые дескрипторы не занимают и места меньше треба!

anonymous
()

Кто ищет порт под Win32 может взглянуть сюда http://people.freebsd.org/~kevlo/postgres/portNT.html правда там с использованием cygwin, но таки работает. Вместо указанного в документе RC2 можно брать последний релиз

mvd
()

Уважаемые, а не подскажет кто, разобрались в 7.1 с типами MONEY, NUMERIC... Приходилось их не использовать в EJB, т.к. в INSERT значения передаются как строчки. Очень не хотелось EJB затачивать специально под Postgres.

В Oracle - все нормально, в Postgrese - такая вот чушь.

anonymous
()
Ответ на: комментарий от jeka

create table (n serial, name char(50)); При этом создается уже упомянутый sequence; При удалении таблицы его надо удалять отдельно. Vic mordoor@mail.ru

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.