Посоветуйте как въехать быстро в PostgreSQL тому, кто шарит в MySQL. Может видяшки какие вводные есть, которые показывают различие?

Просто так въезжать в Postgres не хочешь ты. Знать зачем ты хочешь. Знание это освободит тебя от видяшек

Посоветуйте как въехать быстро в PostgreSQL тому, кто шарит в MySQL. Может видяшки какие вводные есть, которые показывают различие?

Некоторых вещей в Postgres просто нет. И не будет скорее всего. Это верно и для обратной миграции - в MySQL некоторых вещей нет и не будет. Синтаксис разный. Поведение разное. Считай что новую базу осваиваешь. Рекомендкую прочесть раздел 17 официальной доки до того как начнешь вообще трогать. Там пахнет нафталином и многие вещи троганием вообще не достигаются

Ну, концепции-то одинаковые, так или иначе. )

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

Ну, концепции-то одинаковые, так или иначе. )

Нет

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

Собственно проблема, что концепция у них ваще разная. И синтаксис не немного, а ваще различается. И работает немного по другому. И паттерны настройки так прямо скажем ортогональные. Они вообще всё по разному делают

Я о том, что это как ни крути, а все равно реляционная база данных. Синтаксис - это мелочи. А вот с архитектурой нужно разобраться

Да можешь впринципе прямо сюда вопросы задавать

Первое на что я например напоролся когда переходил с мискл - это то что таймстампы в постгре содержат десятитысячные доли секунды)

Чтобы было по нормальному, надо объявлять как timestamp(0)

Вот на таких мелочах спотыкаешься обычно

А то что все разное - это видимо мнение админа. Мне как разработчику показалось все весьма одинаковым.

Вот на таких мелочах спотыкаешься обычно

Спасибо Павел. Я тоже скорее взгляд разработчика имею. Концепции-то все равно знакомые. Буду завтра усиленно углубляться в эту тему )

А то что все разное - это видимо мнение админа. Мне как разработчику показалось все весьма одинаковым.

Хм, а другое экранирование, другая работа с кодировками (только сегодя мозг всем тут вынес же), другая реакция на селекты, другие констрейны, другие инсерты и апдейты (сходи, найди мне REPLACE), другие транзакции, другие вьюхи - это как бы не? Ты там key valuse что ли держишь? Зачем переходил-то? :)

И функции все другие - я с работой с датами чуть голову не сломал

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

Экранирование другое - это что-то из разряда сложнопреодолимых барьеров?

Да. Я например не везде готов взять и переписать все запросы. Более того, я опять забыл как там экраниуется, сходу даже не скажу и полезу опять искать где читал про это в следующий раз

Если не работаешь постоянно то это нормально, а если работаешь то полюбому через некоторое время само в голову влезет.

Я ничего не переписывал, начинал новые проектики делать. Работу с кодировками вообще перестал замечать, как и работу с датами

Да я про работу с кодировками уже всё ппонял. Тут 99% участников даже не задумывались над этим никогда

Ну реально же не было необходимости, все само работает ;)

А то что там надо отсортировать - так это в крайнем случае выносится на програмный уровень, кмк

А то что там надо отсортировать - так это в крайнем случае выносится на програмный уровень, кмк

Это ты SELECT ... ORDER BY ... LIMIT 0,10 на программный уровень выносить собрался?

Да, получаешь список данных и сортируешь как угодно для вывода пользователю

А, с лимитом конечно не прокатит ;)

https://www.postgresql.org/docs/9.5/static/collation.html а вот это все не подходит?

google UCA

Что-то мне кажется что решение проблемы есть. Если чуть дольше поискать..

искаропки нет. пока единственное что есть - модуль для 9.3 который надо вкомпилировать

Я тут подумал, может быть это и правильно что пг опирается на системную локаль? Все таки операционная среда - это то что должно предоставлять как можно больше средств для обработки информации

А то получается что пг отсортирует по своей локали, другие программы по каким-то своим. Бардак получается.

Я тут подумал, может быть это и правильно что пг опирается на системную локаль? Все таки операционная среда - это то что должно предоставлять как можно больше средств для обработки информации

угу. а притом что системные локали они разные у систем - получается полный ахтунг

В документации сказано, что если локаль не соответствует набору хранимых символов, будут проблемы с сортировкой, индексами, функциями upper() и lower(). Буквально сегодня столкнулся с тем, что в кластере во всех параметрах lc_ указано US_en.UTF8, но ни одной из выше перечисленных проблем с кириллическими строками не воспроизводится

Что я делаю не так?

Там проблемы со смесью кириллических и национальных строк

(насколько я понял)

В документации сказано, что если локаль не соответствует набору хранимых символов, будут проблемы с сортировкой, индексами, функциями upper() и lower(). Буквально сегодня столкнулся с тем, что в кластере во всех параметрах lc_ указано US_en.UTF8, но ни одной из выше перечисленных проблем с кириллическими строками не воспроизводится

то есть можно с локалью не бороться? Я как раз сейчас этот вопрос решаю )

угу. а притом что системные локали они разные у систем - получается полный ахтунг

А они разве разные? Может быть разный набор, но юникод символы то одни и те же

Символы — одни, наборы — нет.

В документации сказано, что если локаль не соответствует набору хранимых символов, будут проблемы с сортировкой, индексами, функциями upper() и lower(). Буквально сегодня столкнулся с тем, что в кластере во всех параметрах lc_ указано US_en.UTF8, но ни одной из выше перечисленных проблем с кириллическими строками не воспроизводится

потому что набор ранимых символов UNICODE в UTF-8. а ланг для аппер/ловвер/сортировки

Там проблемы со смесью кириллических и национальных строк

скорее смесью азиатских и паневропейских. у кириллицы такой проблемы нет

Символы — одни, наборы — нет.

я думаю именно набор диапазона там вообще никак не роляет

Для сортировок-то не влияет? Ага, щас.

А они разве разные? Может быть разный набор, но юникод символы то одни и те же

правила сортировок разные. у fbsd, osx и linux совсем разные

Для сортировок-то не влияет? Ага, щас.

но это не набор символов, а алгоритм сортировки

Very interesting

ну это google libc UCA

google osX UCA locale

ну и так далее

даже гуглится что sort в linux и OSX по-разному отдаёт

эээээ

вот, в официальном PG нет локалей

Это про Docker

Фил, а как надо то ?

я не понимаю грубину проблемы

у меня плохо будут сортироваться данные при не правильной локали ?

проблема только с сортировкой или еще всякими "a" in str

давайте придумаем как локаль поменять )) У меня что-то не получается с налета

ERROR: S client not available

у меня плохо будут сортироваться данные при не правильной локали ?

А я не уверен в поведении PG при заданной одной локали и отсутсвии оной в системе

Для генерации локали можно использовать: dpkg-reconfigure locales Но там диалог, в котором нужно выбрать нужную локаль для генерации. Это не подходит для докера, естественно. Задать значение генерируемой локали нельзя, похоже (

locale-gen --lang ru

localedef -i ru_RU -f UTF-8 ru_RU.UTF-8 ?

locale-gen --lang ru

Отлично! Это оно, спасибо ) Осталось локаль установить

export LANG=ru_RU.UTF-8 ?

export LANG=ru_RU.UTF-8 ?

Вау, тезка, все работает! Спасибо огромное!! ))

и я бы еще добавил export LC_MESSAGES=C хуже нету, чем когда сообщения об ошибках начинают не на аглицком валиться

особенно когда их нагуглить пытаешься ;)

это точно

Запишу в Gist ))

Но вот затем PG валится... печально

LOG: invalid value for parameter "lc_messages": "en_US.utf8"

потому что должно быть "C"

так оно же и есть C после export LC_MESSAGES=C

en_US.UTF-8

без смены локали все работает как раз

а, нет, этот момент пройден, просто команда одна не применилась... Но едем дальше ))

The files belonging to this database system will be owned by user "postgres". This user must also own the server process. initdb: invalid locale settings; check LANG and LC_* environment variables

Короче, разобрался. Нужно еще установить LC_CTYPE и LC_ALL. Если они пустые, то PG не запускается.

?

LC_ALL вроде не нужен

LC_Collate и lc_ctype

да, если поставить LC_ALL, то там все параметры перезадаются

LC_ALL вроде не нужен

Чудеса какие-то, но реально если LC_ALL пустой, то PG падает

Может там еще какой-то скрытый параметр есть, который наследуется от LC_ALL?

ну выстави сначала LC_ALL, а потом перегрузи LC_MESSAGES

ну выстави сначала LC_ALL, а потом перегрузи LC_MESSAGES

Не дает, если LC_ALL стоит ru_RU.UTF-8, то все параметры тоже выставляются так.

фигня какая-то ?