maxcom (*) (2002-02-07 12:57:43.0) Mogesh raskazat svoi vpechatleniya po etoi versii ???

Ya tak ponyal ti uge poproboval !

интересно, а раьота с xml в нем исключительно через udf?
а сам он просто как текст его хранит?
и в чем заключается его интернационализация?

> Mogesh raskazat svoi vpechatleniya po etoi versii ???

Неа, я еще 7.1 не попробовал :-)

2Avel:
текст хранит, как скажешь (если включена multibyte) - koi8, cp1251, utf8 доступны.
локализации там 3 ...

текст хранит, как скажешь (если включена multibyte) - koi8, cp1251, utf8 доступны.
а если внутри он хранит utf8 то отдает как попросишь?
в кои8 1251 utf8.
или только как лежит-так и получай?
что значит 3 локализации? три кодировки одних и тех же сообщений и ошибок на русском?

> а если внутри он хранит utf8 то отдает как попросишь? > в кои8 1251 utf8. > или только как лежит-так и получай?

как попросишь так и отдает

AB

Вах! Наконец - то поаравили VACUUM - затрахал он меня уже чесс слово.

Изменения, в общем то радуют, но настолько ли они революционны, чтобы перейти сразу к 7.2? Какие, кстати принципы нумерации версий у постгреса?

Пожалуйста, объясните чайнику, что лучше: PostgreSQL или MySQL? Про второй-то еще читал, а про первый что-то ничего не попадалось.

Oracle лучше, но он платный. ;-)
Шучу, кАнЭШнА (не насчет платности). ;-)

Сергей К.,
Н.Новгород

>Пожалуйста, объясните чайнику, что лучше: PostgreSQL или MySQL? Про >второй-то еще читал, а про первый что-то ничего не попадалось.

Esli ti pro DB (ORACLE,SYBASE,DB2 || Theory ) ne chital to i raskazat tebe ne prosto.

Do vstrech .

> Какие, кстати принципы нумерации версий у постгреса?

Смена первой цифры - milestone, как у всех смена второй - накопившиеся enhancements, требующие dump/restore базы и нового initdb смена третьей - багфиксы и мелкие улучшения, не требующие изменения баз. Скажем 7.1.3 от 7.1.2 отличался в основном документацией.

Над локализацией в pgsql потрудилось много нашенских, так что там сделано все на совесть, всякие cyrillic-recode встроены, да и utf рулит..

классно кстати сложилось - к RH7.2 и PostgreSQL 7.2 подогнался... всерьез и надолго:-)

Re:

> что лучше
Если кратко, то MySQL быстр на работе с единичными таблицами (настолько же, насколько тОрмозен при работе сложных запросов), Postgres - во всём остальном - приемлемо реагирует на сложные запросы, имеет нормальный механизм поддержки транзакций и обеспечения ссылочной целостности.

А мне кажется где-то сообщение поподалось (м.б. даже здесь), что якобы PostgreSQL больше не будет развиваться, типа контора закрылась и т.п. Соврали значит или я что-то путаю? (много сейчас всяких SQL-ов делается).

> А мне кажется где-то сообщение поподалось (м.б. даже здесь), что якобы PostgreSQL больше не будет развиваться, типа контора закрылась и т.п.

Закрылась (или не закрылась, но имеет проблемы) контора, занимавшаяся коммерческой поддержкой PostgreSQL. Разработка постгресса продолжается ;-)

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

Люди!
Кто имел дело с InterBase & PostgreSQL?
поделитесь впечатлениями InterBase vs. PostgreSQL

На удивление, апгрейд прошел без проблем. Субъективно стал быстрее работать. Да и Vacuum быстро проходит и не подвисает. Обещают сообщения об ошибках на родном языке. Из минусов - они собираются менять структуру Limit Offset со следующего релиза и перестал работать ZDE. Никто других клиентов под винду не знает?

угу, локализовали( как же господи ну какая разница нормальному человеку сообщения по русски или по англицки?( а сортировка win1251 как не работала так и неработает(((((( может я конечно что не так делаю - но сколько я в форуме не спрафивал - тишина. сначала все на букву Р потом... да что тут говорить - АБЫДНО ДА?!(

IB vs Postgre

Практически равноценны. К чему больше привык, то и лучше. Я, например, склоняюсь к IB (Win32/Linux/FBSD). Первая любовь. Хотя сейчас юзаю Postgre на Linux.

И upper кривой. UPPER('чего это я') все видели? В Win1251. Не перелопачивать же кучу баз в другую кодировку. Пока апперим руками :(

Почему-то у меня сортировка в win1251 как работала начиная с ранних бэт 7.1, так и работает.

Хитрость в том, что локаль, с которой выполняетс initdb и с которой запускается сервер, должна совпадать с кодировкой хранения.

А у меня - работает. См мое предыдущее сообщение.

Пришлось даже в инсталлятор Communiware засунуть проверку на этот самый upper, чтобы чайника, который систему ставит, сразу за руку поймать, что криво запустил Postgres.

А если прямо запустить - все работает - и сортировка, и upper. Не работали (в 7.1) индексы в запросах с Like. Ну да это пережить можно.

Narod, a gde mozhno skachat', odbc drivers i libpq pod win ??

Народ!
подскажите ссылочку на хорошую доку на русском по субж.
Буду премного благодарен.

> сортировка win1251 как не работала так и неработает(((((( может я конечно что не так делаю - но сколько я в форуме не спрафивал - тишина.

ну млин... исходники же на руках, пофиксай сам! дел на 10 минут... я еще помню когда PL/SQL процедуры у него неявно не могли превышать ~4K текста по объему, делал свой патчик.... С тех пор вроде все устраивает, CPU Alpha-багфиксы они еще в ветку 6.5 merge-нули, так что все пожалуй...

ну что мне не понравилось - в очередной раз перетрясли расположения всяких headers (ну в rpm по крайней мере). лана еще сторонная тулза которая кроме libpq-fe.h ниче в жизни не видала, а когда с Postgres SPI активно работаешь, так каждый X.X релиз довольно дорого стоит в плане перехода... вспомнить хотя б миграцию с 7.0 на 7.1... чертовы любители макросов :-))))

IB/FB vs Postgre

Честно говоря, IB/FB, имхо, все-таки уступает Postgre. 1. В IB/FB ограничена длина записи (в Postgre правда она тоже не так уж и давно неограниченной стала) 2. Кто-то жаловался, что Postgre индексы для оператора LIKE не использует (или не всегда использует?), IB/FB их просто отказывается строить для строк длиннее 252 (для первичных ключей 84) байт. 3. Невозможность написать функцию (не процедуру,а именно функцию), иначе как в UDF, что не всегда удобно. 4. Отсутствует Select ... from (Select ... )

ну и так, по мелочи неприятности всякие, хотя многим все вышеперечисленное и не нужно, а в этом случае IB вполне удобна как для начала, так и для дальнейшего развития. Разве что непонятна её дальнейшая судьба: IB разделилась на две ветки (IB и FB, и они уже не полностью совместимы между собой), Borland исходники закрыла, и нет никакой гарантии, что со временем так же не поступит IB Phoenix (мэйнтейнер FireBird).

В общем пусть каждый решает для себя сам, что лучше. Лично я буду потихоньку мигрировать на Postgre.

2 Asteroid (*) (2002-02-12 11:59:51.0)
Не подскажешь какой тип данных у postgresql предназначен для хранения двоичный данных (массива размером меньше 1000 байт)?

2 anonymous (*) (2002-02-12 14:30:52.0)

тебе его в каком виде хранить-то надо? в виде битовой последовательности (BIT(n) или BIT VARYING(n)), а если ты хочешь полей массивов, то они есть: как одно-, так и многомерные, как фиксированного размера, так и переменного, например integer[][]

2 Asteroid (*) (2002-02-12 17:43:50.0)
> тебе его в каком виде хранить-то надо?
В виде массива байт (в оракле это raw(n), в mssql - binary или image).

Используй тип bytea. В версии 7.2 он уже более-менее нормально документирован... Хотя в 7.1 тоже работает.