>И установка datestyle? по умолчанию

не знаю как поменять.

>И установка datestyle? по умолчанию

А какая? ;) SHOW datestyle;

DateStyle ----------- ISO, MDY (1 row)

не знаю как поменять.

SET datestyle = 'ISO, DMY';

DateStyle ----------- ISO, MDY (1 row)

Ну вот поэтому-то и не работает. Ваша дата воспринимается как: день 2018, месяц 8, год 14.

SET datestyle = 'ISO, DMY';

о! именно это я и искал

Ну вот поэтому-то и не работает. Ваша дата воспринимается как: день 2018, месяц 8, год 14.

я понимаю что не работало. не знал как задать этот формат.

спасибо большое

хм... найти бы возможные варианты значений для datestyle

я понимаю что не работало. не знал как задать этот формат.

Вообще, кстати, протокол PostgreSQL позволяет задавать клиентские параметры сессии прямо при соединении... но это надо смотреть, поддерживается ли это используемым Вами API. Но если не поддерживается, можно использовать "SET datestyle" (или просто установить на сервере / для пользователя / для базы... как хотите).

хм... найти бы возможные варианты значений для datestyle

https://www.postgresql.org/docs/current/static/runtime-config-client.html#GUC-DATESTYLE

? супер. А то меня всё ведёт на документацию для SET

жаль, что нельзя сказать: set datestyle to 'DD -- MM -- YYYY';

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

Добрый день друзья Подскажите пожалуйста как установить максимальный лиминт на селект

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

вы не поверите, LIMIT N

я имею в виду на стороне базы ограничить это а не в самом запросе

а, понял

думаю, такого параметра нет

может у когонибудь есть идея как этого достичь?

зависит от того, какую проблему вы решаете. может быть, вам подойдет вариант создать View с лимитом?

тогда на этот View можно будет делать селект без указания лимита

хмм можно поробовать

спасибо

может у когонибудь есть идея как этого достичь?

А зачем?!

не опнимаю вашего удивления

есть требование по которому база не должна возвращать по селекту больше определенного количетсва записей вот и все

на самом деле, это "требование" уже звучит как решение какой-то другой проблемы

это не продакшн а просто тренировка

на вход мы получаем строку с произвольным селект запросом

и на уровне базы нужно както ограничить максимальный лимит

с вью видимо так не получится

вроде может получиться

(если я правильно себе представляю, как работает VIEW + LIMIT)

есть требование по которому база не должна возвращать по селекту больше определенного количетсва записей вот и все

А требования иногда возвращать данные из /dev/random у Вас нет? ;) А то оно примерно такое же "нормальное" для реальных систем.

это не продакшн а просто тренировка

А, всё, вижу..

это не реальная система я уже упомниал об этом выше

я тут проверил. да, если делать запрос из VIEW с лимитом, то возвращается не больше строк, чем задано в лимите на VIEW.

вроде может получиться

может я чегото не понимаю но если мы сделаем лимит на вью то потерям данные для селекта не так ли

что значит потеряем? не очень понял

а, понял

да, потеряем

вот в этом то и проблема

так что да, не подходит

вот в этом то и проблема

Ну а почему в приложении это не решать?

не очень бы хотелось парсить запрос и проверять лимит

мне кажется за это баща должна отвечать

не очень бы хотелось парсить запрос и проверять лимит

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

видимо придется разобраться таки с курсорами

видимо придется разобраться таки с курсорами

Для Вашей задачи, по идее, просто. Что-то вроде: CREATE TABLE t(n) AS SELECT n FROM generate_series(1, 100) AS g(n); -- BEGIN; DECLARE cursor1 NO SCROLL CURSOR FOR SELECT * FROM t; FETCH 10 FROM cursor1; -- сколько нужно COMMIT;

спасибо

буду разбираться

Вопрос по терминологии. Кто-нибудь помнит, как называется паттерн, когда помимо свойства какого-либо объекта в одной таблице хранят еще и интервал, когда оно было актуально? Т.е. типа такого: tariff_id, project_id, date_start, date_finish 1, 100, '2018-01-01', '2018-05-01' 2, 100, '2018-05-01', null

Справочник с поддержкой историчности

Бесплатные централизованные системы резервного копирования никто не подскажет, кто какие использует?

Бесплатные централизованные системы резервного копирования никто не подскажет, кто какие использует?

бакула

бакула

+

Бесплатные централизованные системы резервного копирования никто не подскажет, кто какие использует?

bareos. форк бакулы, но полностью opensource, в отличие от бакулы

Эммм... А бакула уже умеет БД резервно копировать? По-моему, тут более уместно вспомнить barman и pgbackrest

Спасибо!

Подскажите, пожалуйста. В расширении pg_stat_statements в каких единицах измерения представлено время выполнения запроса, в частности колонка - total_time

total_time double precision Total time spent in the statement, in milliseconds https://www.postgresql.org/docs/9.4/static/pgstatstatements.html

привет. Подскажите пожалуйста какое поле используют для хранения значения криптовалюты в бд?

привет. Подскажите пожалуйста какое поле используют для хранения значения криптовалюты в бд?

которое сумму хранит? или че?

которое сумму хранит? или че?

код счета

сам счет

varchar

привет. Подскажите пожалуйста какое поле используют для хранения значения криптовалюты в бд?

text

https://avitotech.timepad.ru/event/798808/

text

А почему так по-богатому?

А почему так по-богатому?

А как по-бедному?

А почему так по-богатому?

В смысле? Это же по сути текстовое поле, как я понял. Вот и советую соответствующий тип.

В текст, как и в варчар без указания длины, можно запихать 1гб мусора

Хорошей практикой считается делать ограничение длины полей, если оно известно

Хорошей практикой считается делать ограничение длины полей, если оно известно

Кем это считается хорошей практикой? ;) Например: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_varchar.28n.29_by_default

сомнительное обоснование в wiki, ну да ладно)

сомнительное обоснование в wiki, ну да ладно)

ну ничто не мешает ограничитиь длинну

и даже создать свой тип

ограничив правилами

сомнительное обоснование в wiki, ну да ладно)

Хмм... что в нём сомнительного? По-моему, вполне логично — если Вы хотите наложить какие-то ограничения на поле, так и используйте CHECK CONSTRAINT (или DOMAIN).

если при обьявлении типа можно ограничить его сверху (а в 99% случаев ограничения только по MAX длине), зачем дополнительный констрейт?

если при обьявлении типа можно ограничить его сверху (а в 99% случаев ограничения только по MAX длине), зачем дополнительный констрейт?

в постгресе text и varchar ничем не отличаются в реализации. и на памяти/скорости не сэкономите

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

в постгресе text и varchar ничем не отличаются в реализации. и на памяти/скорости не сэкономите

я это знаю

если при обьявлении типа можно ограничить его сверху (а в 99% случаев ограничения только по MAX длине), зачем дополнительный констрейт?

> в 99% случаев ограничения только по MAX длине Ну, я бы не сказал — мне кажется, другие constraints бывают почаще, чем в 1% случаев. А так, затем, что (IMHO): . Логично использовать для всех ограничений полей одно средство. . У CONSTRAINT может быть название, которое может быть с пользой применено в приложении (ошибка про malformed_account_code как-то "веселее", чем "value too long for type character varying(x)" (тут ещё, кстати, и непонятно, про какое поле ошибка)). . Ну и CONSTRAINT — это "логическое" ограничение, оно выражает намерение, а varchar(x) — "физическое" (аналогичное PRIMARY KEY, UNIQUE/EXCLUSION CONSTRAINTS и т.п.). И это даже может быть полезно, если база следует правилу по возможности определять ограничения таким образом — легче делать их review и т.п.

в постгресе text и varchar ничем не отличаются в реализации. и на памяти/скорости не сэкономите

Это, как раз, не должно иметь существенного значения в проектировании. А то получается модель, основанная на преждевременной оптимизации. Обычно, результаты такого подхода просто "замечательны" (легче сразу выбросить). :(

Это, как раз, не должно иметь существенного значения в проектировании. А то получается модель, основанная на преждевременной оптимизации. Обычно, результаты такого подхода просто "замечательны" (легче сразу выбросить). :(

а где тут оптимизация?

а где тут оптимизация?

> на памяти/скорости не сэкономите Этот довод как-то связан с оптимизацией, Вам не кажется? ;)

ограничения удобно делать в валидаторах в коде, чтобы база хранила, а код логику обрабатывал

ограничения удобно делать в валидаторах в коде, чтобы база хранила, а код логику обрабатывал

Вы же знаете, что по этому поводу есть два "враждующих" лагеря, правда? Так вот, я из другого лагеря... ;)

понятно)

ограничения удобно делать в валидаторах в коде, чтобы база хранила, а код логику обрабатывал

В коде на стороне постоянно что-то забывают проверять, а вам потом с этим мусором разбираться.