| |
| 2.3, Аноним (-), 21:13, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Имеете отношение к разработчикам? Скажите, вы с 1С сотрудничаете, или они сами свою версию пилят?
| | |
| |
| 3.5, Аноним (-), 22:42, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
AFAIK, первая адаптация для 8.2 была сделана по индивидуальному контракту с несколькими разработчиками, теперь сами.
| | |
|
|
| 1.6, BlakeR (?), 08:06, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 >> для хранения структурированных наборов данных в формате JSON
Уход в NoSQL? Оригинально.
| | |
| 1.10, Stax (ok), 16:42, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > Выражение "ALTER SYSTEM SET" для изменения настроек, заданных в файле postgresql.conf, из командной строки SQL или удалённых клиентов. Например, "ALTER SYSTEM SET log_min_duration_statement = '5s'";
Хех. Идем по пути оракла (с 10-ти летним отставанием) :))
В будущем, вероятно, нас так же ожидает новый бинарный конфиг, который удобнее править из БД (чтобы не спотыкаться на парзинге написанных пользователем конструкций - все-таки модифицировать текстовый конфиг из программы не очень приятно), потом постепенный отказ от текстового в пользу бинарного и необходимость менять все настройки только через ALTER SYSTEM...
| | |
| |
| 2.11, rob pike (?), 16:50, 16/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Так конфиг и так уже весь в БД, зачем ему еще и бинарным быть?
>модифицировать текстовый конфиг из программы не очень приятно
Основная цель ALTER SYSTEM SET была в том чтобы менять эти настройки без downtime
| | |
| |
| 3.12, Аноним (-), 17:06, 16/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Какой ещё даунтайм? Роб Пайк не знает про SIGHUP? Почему тебе не стыдно с такими познаниями подписываться именем Роба?
| | |
| |
| 4.14, rob pike (?), 17:56, 16/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Вы пробовали с SIGHUP-то? Чтоб с тредами, надежно и на всех платформах.
Что-то мне подсказывает что нет. У разработчиков OpenLDAP можете спросить, они пытались.
В итоге плюнули и сделали cn=config. Что в общем и правильно.
| | |
|
| 3.21, Stax (ok), 15:58, 19/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Так конфиг и так уже весь в БД, зачем ему еще и
> бинарным быть?
>>модифицировать текстовый конфиг из программы не очень приятно
> Основная цель ALTER SYSTEM SET была в том чтобы менять эти настройки
> без downtime
Во-во, в оракле так же думали. А в итоге путь привел к полностью бинарному конфигу, а текстовый давно "deprecated".
Это просто логическое продолжение. Хочется: менять конкретную настройку надежно и, по возможности, автоматически (из скрипта / по ssh / без downtime). Решение: вместо костыля в виде правки конфига sed'ом и SIGHUPа, делаем представление конфига в программе и возможнсть менять специальной командой.
Дальше что? Хочется иметь возможность вносить перманентные изменения. Значит, возможность сохранять конфиг из программы. Начинается конфликт: когда текстовый конфиг может править и админ, и программа, получается ммм не очень хорошо и неудобно обоим. Почти везде такое противостояние заканчивается бинарным конфигом. Так вышло и в оракле, и, уверен, выйдет и в постгресе, если они продолжат логическую цепочку.
| | |
|
| 2.13, Аноним (-), 17:12, 16/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Выражение "ALTER SYSTEM SET" для изменения настроек, заданных в файле postgresql.conf, из командной строки SQL или удалённых клиентов. Например, "ALTER SYSTEM SET log_min_duration_statement = '5s'";
> Хех. Идем по пути оракла (с 10-ти летним отставанием) :))
Глупости то не пишите, PostgreSQL самостоятельная СУБД к Oracle не имеющая отношения. ALTER SYSTEM SET сделали что бы редактировать конфигурацию без SSH и к бинарным конфигам Oracle это никакого отношения не имеет.
| | |
| |
| 3.16, Аноним (-), 00:07, 17/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну зачем ты так бредишь. Очень многие прикольные штучки для рСУБД действительно давно сделали в оракд дб и PG постепенно делает точно такие же у себя. Иногда из-за того, что иначе нормально и не сделать, а иногда просто копируют фичу.
| | |
| |
| 4.17, Аноним (-), 00:35, 18/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Типа plperl, plpython, и т.д. которых в oracle отрадясь не было и не будет.
| | |
| |
| 5.20, Stax (ok), 15:51, 19/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Типа plperl, plpython, и т.д. которых в oracle отрадясь не было и
> не будет.
Ну вы же понимаете, что хотя для костыльной разработки это "прикольные" возможности, но на практике в оракле и pl/sql мощнее, чем pl/pgsql, и тяжелая артиллерия в виде java доступна. И на них можно сделать все, что и на plpython и иже с ними. Да, если разработчик не знает джаву и не хочет учить pl/sql, наличие plpython может быть удобным - иногда это важно, но если подходить серьезно, оверхед на запуск plpython кода и передачи параметров туда-сюда значительно выше, чем у откомпилированного pl/sql - т.е. под нагрузку не воткнешь..
А в общем, это бессмысленный спор - в оракле с его Ада-наследием и строгостью не будет многих приятных небольших фич из постгреса - например, такого количества типов данных и специфичных функций для работы с ними - но отрицать, что оракл во многом все еще "локомотив" индустрии и постгрес еще очень много полезного может оттуда взять (и периодически берет) тоже глупо.
| | |
|
|
|
| 2.15, Аноним (-), 18:36, 16/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
pfile вполне себе текстовый, и модифицировать его весьма удобно с последующим create spfile frpm pfile = '<path>';.
| | |
| |
| 3.19, Stax (ok), 15:44, 19/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Текстовый, да deprecated, многие вещи официально через pfile сделать "нельзя" :)
Ну и данная конструкция переопределит все, что было до этого в spfile, так что.. очень крайний случай.
| | |
|
|
|
