Впредь буду умнее

Спасибо, по глупости заменил файлы конфига в файловом менеджере из под рута

Все через это проходят. ? А ещё нужно не забывать про selinux. Очень неприятная вещь.

как динамически создават таблицы с помощью psycopg2 и executemany? он их оборачивает в кавычки

Так не надо динамически создавать таблицы... Антипаттерн

Парни, привет. Задача следующая.. Есть таблица tariffs с 3-мя столбцами - prefix, name, price в столбце prefix прописан префикс направления, например 7926 и т.д. Как получить значение price используя полный номер (destination_number) т.е. начало такое SELECT price FROM tariffs WHERE 79268502525........ Поскажите, пжлст, как вытянуть значение price?

Написать запрос...

@mifastiy будет жить. Поприветствуем!

Grisha будет жить. Поприветствуем!

как динамически создават таблицы с помощью psycopg2 и executemany? он их оборачивает в кавычки

from psycopg2.sql import SQL, Identifier cursor.mogrify(SQL("SELECT * FROM {}").format(Identifier('test_tbl'))) вот такой запрос строит, эскейпит идентификаторы в двойных кавычках: b'SELECT * FROM "test_tbl"' А для чего понадобилось создавать таблицы динамически?

Unknown будет жить. Поприветствуем!

Привет! Тут есть кто онлайн?

Я вот курс SQL прошел. Но там было мало да и толком ничему не научился. Какие книжки лучше читать чтоб научиться?

Если что курс был краткий и прошел его за 4 часа

курс на постгрепро скачай

А в чем разница между SQL и PGSQL?

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

Эх, лан, я пойду

Если что курс был краткий и прошел его за 4 часа

быстрый какой. недельку посидеть тут и просто почитать общение стоит многих уроков )

Попробуй решить прикладную задачу

По ходу дела разберешься в целой куче нюансов

Ты же хочешь в дев? Не в администрирование, надеюсь

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

О. Лесли на аве.

Ты же хочешь в дев? Не в администрирование, надеюсь

тут по разному может сложиться. мне админства хочешь не хочешь а хапнуть пришлось (

тот же ворк_мем в конфиге править это админство например?

Я вот курс SQL прошел. Но там было мало да и толком ничему не научился. Какие книжки лучше читать чтоб научиться?

Мартин Грубер. Понимание SQL

Задачи администрирования значительно шире, чем правка конфигов. Граница между разработчиками и админами размыта

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

Ну например динамически нам нужно создавать таблицы когда мы до самого старта программы не знаем ни сколько у нас будет объектов ни их имена, а нам нужны таблицы с именами объектов. Понимаю что можно сделать general таблицу, и как отдельным полем указывать имена объектов, но как-то не хочется делать одну таблицу размером в сотни гб.

Ну например динамически нам нужно создавать таблицы когда мы до самого старта программы не знаем ни сколько у нас будет объектов ни их имена, а нам нужны таблицы с именами объектов. Понимаю что можно сделать general таблицу, и как отдельным полем указывать имена объектов, но как-то не хочется делать одну таблицу размером в сотни гб.

Это вообще странная архитектура. Скорее всего неправильное проектирование. Даже сложно представить задачу, где именно так пришлось бы решать.

@cavef1sh будет жить. Поприветствуем!

Это вообще странная архитектура. Скорее всего неправильное проектирование. Даже сложно представить задачу, где именно так пришлось бы решать.

Почему же, гибкие системы (платформы) конфигурируемые без вмешательства программистов, когда через админку, можно накликать справочники, документы, заказы и т.д, описать их особенности, логические связи еще какие то штуки. Аля clientbase, или 1C на самом базовом уровне.

Почему же, гибкие системы (платформы) конфигурируемые без вмешательства программистов, когда через админку, можно накликать справочники, документы, заказы и т.д, описать их особенности, логические связи еще какие то штуки. Аля clientbase, или 1C на самом базовом уровне.

Такого не бывает.

Это вообще странная архитектура. Скорее всего неправильное проектирование. Даже сложно представить задачу, где именно так пришлось бы решать.

+1

Ну например динамически нам нужно создавать таблицы когда мы до самого старта программы не знаем ни сколько у нас будет объектов ни их имена, а нам нужны таблицы с именами объектов. Понимаю что можно сделать general таблицу, и как отдельным полем указывать имена объектов, но как-то не хочется делать одну таблицу размером в сотни гб.

Если тебе нужно динамически создавать таблицы в БД (не временные), то это ошибка проектирования.

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

Если тебе нужно динамически создавать таблицы в БД (не временные), то это ошибка проектирования.

ну а иметь одну таблицу на 3 ТБ данных в год это не ошибка проектирования?

Я не серию данные в БД байтами и тебе не советую. Вполне возможно, что и нет, не ошибка.

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

кароче у меня с запросом видимо беда. не пойму где ошибка, то ли на фронте, то ли на беке. Скорее всего бэк конечно, что в принципе логично. В общем суть. Есть отчет, вводим в поля начальную дату и конечную. отчет должен показывать записи, которые входят в этот интервал. В БД есть таблица с записями, там есть поле с датой, дата хранится в формате timestamptz. Сейчас там такая запись, например: 2018-08-27 09:44:35 Сама интернет-площадка умеет отслеживать локальное время. Так вот, если локальное время стоит GMT+3, т.е время моего региона, то отчет формируется верно, при вводе диапазона дат показываются верные записи. Однако, если изменить локальное время через настройки винды и поставить GMT+4, то с тем же интервалом дат записи показываются уже другие. Т.е допустим ввожу 23 - 26 августа, показывается еще запись за 22. Если же я перехожу снова в свой часовой пояс, то записи показываются верно. Я думаю там есть какая-то проблема именно с хранением даты в БД и форматом timestamptz. В чем может быть проблема?

кароче у меня с запросом видимо беда. не пойму где ошибка, то ли на фронте, то ли на беке. Скорее всего бэк конечно, что в принципе логично. В общем суть. Есть отчет, вводим в поля начальную дату и конечную. отчет должен показывать записи, которые входят в этот интервал. В БД есть таблица с записями, там есть поле с датой, дата хранится в формате timestamptz. Сейчас там такая запись, например: 2018-08-27 09:44:35 Сама интернет-площадка умеет отслеживать локальное время. Так вот, если локальное время стоит GMT+3, т.е время моего региона, то отчет формируется верно, при вводе диапазона дат показываются верные записи. Однако, если изменить локальное время через настройки винды и поставить GMT+4, то с тем же интервалом дат записи показываются уже другие. Т.е допустим ввожу 23 - 26 августа, показывается еще запись за 22. Если же я перехожу снова в свой часовой пояс, то записи показываются верно. Я думаю там есть какая-то проблема именно с хранением даты в БД и форматом timestamptz. В чем может быть проблема?

в функциях использую дату в формате timestamp without time zone

может и вам поможет (я не настоящий сварщик в postgres ? )

т.е мне формат данных timestamptz надо поменять на какой-то другой в БД?

кароче у меня с запросом видимо беда. не пойму где ошибка, то ли на фронте, то ли на беке. Скорее всего бэк конечно, что в принципе логично. В общем суть. Есть отчет, вводим в поля начальную дату и конечную. отчет должен показывать записи, которые входят в этот интервал. В БД есть таблица с записями, там есть поле с датой, дата хранится в формате timestamptz. Сейчас там такая запись, например: 2018-08-27 09:44:35 Сама интернет-площадка умеет отслеживать локальное время. Так вот, если локальное время стоит GMT+3, т.е время моего региона, то отчет формируется верно, при вводе диапазона дат показываются верные записи. Однако, если изменить локальное время через настройки винды и поставить GMT+4, то с тем же интервалом дат записи показываются уже другие. Т.е допустим ввожу 23 - 26 августа, показывается еще запись за 22. Если же я перехожу снова в свой часовой пояс, то записи показываются верно. Я думаю там есть какая-то проблема именно с хранением даты в БД и форматом timestamptz. В чем может быть проблема?

Таки 23.08 00:00 GMT+03 это 22.08 23:00 GMT+04

т.е мне формат данных timestamptz надо поменять на какой-то другой в БД?

Нет. Вам нужно просто правильно работать с timestamptz в Ваших приложениях.

Кстати: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

timestamptz это же с учетом timezone формат

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

Скорее внутри сравнивать правильно с учётом часового пояса.

timestamptz это же с учетом timezone формат

Это формат, который хранит абсолютное время, и преобразует в локальное при I/O (в соответствии с timezone сессии).

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

Правильно устанавливать timezone, и передавать правильные значения (и интерпретировать их), и всё.

всем

посоны, помогитедоавить скрипт на удалние первых 4 записей.

вот есть такой скрипт https://pastebin.com/D4sttRUM

надо дописать. чтобы удаляоось первые 4 записи

типа не показывать первые 4 записи?

или прям удалять из базы?

По каким причинам постгрес мог внезапно решить использовать другой индекс вместо того, которым пользовался всё время?

По каким причинам постгрес мог внезапно решить использовать другой индекс вместо того, которым пользовался всё время?

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

До VACUUM ANALYZE:

Притом, что сегодня он запускал автовакуум/автоаналайз на эту таблицу

или прям удалять из базы?

прям удалить

И произошло оно, конечно же, когда я был в отпуске :D

@falselena будет жить. Поприветствуем!

прям удалить

ну там две таблицы, нужно удалить из обоих?

почему две таблицы. таблица олна. просто название потягивается из второй

я написал вот так DELETE FROM public."AO_2C4E5C_MAILITEM" WHERE ID = '2862'; по получил ошибку

в таблице есть такой столбец,не системный

А не те же ли грабли? @bazav

я не так связь там сделал ))

я сделал по ID

А не те же ли грабли? @bazav

ты о чем ?

причем тут связь ?