Size: a a a

pgsql – PostgreSQL

2020 June 15

Т

Т.А in pgsql – PostgreSQL
конфиг вроде применился, но слушает дефолтный порт
источник

s

sexst in pgsql – PostgreSQL
Т.А
конфиг вроде применился, но слушает дефолтный порт
У вас постгрес 3 дня как не перезапускали судя по выводу systemd.
И выкиньте вы уже дедушку netstat, есть ss.
ss -t -l -p -n | egrep "[56]43[23]"
источник

Т

Т.А in pgsql – PostgreSQL
sexst
У вас постгрес 3 дня как не перезапускали судя по выводу systemd.
И выкиньте вы уже дедушку netstat, есть ss.
ss -t -l -p -n | egrep "[56]43[23]"
да да, перезагрузил и заработало
источник

s

sexst in pgsql – PostgreSQL
Т.А
да да, перезагрузил и заработало
Если что, релоад некоторые настройки не применяет, только рестарт)
источник

Т

Т.А in pgsql – PostgreSQL
sexst
Если что, релоад некоторые настройки не применяет, только рестарт)
да да. я настроил и запустил командой старт. думал, что баунсер ещё не запускался ни разу, а он оказывается активен с момента установки
источник

GB

George Bessonov in pgsql – PostgreSQL
Yaroslav Schekin
Тут никакого кода нет, только какая-то картинка.

> В моём понимании, информация о таймзонах должна была обрезаться на вставке

Странно... вроде бы, в документации были объяснения, с примерами...
Ладно, по шагам:
timezone('Europe/Moscow', '2020-06-11 08:28:27'::timestamp AT time ZONE 'utc'),
Работает так:
1. '2020-06-11 08:28:27'::timestamp AT TIME ZONE 'UTC' — это "вот тебе снимок, он был сделан в time zone UTC, преобразуй его в абсолютное время". Результат: '2020-06-11 08:28:27+00' (или эквивалентное '2020-06-11 11:28:27+03' и т.д. и т.п. — что Вы увидите, зависит только от timezone сессии, но это один и тот же момент времени, timestamptz).
2. timezone('Europe/Moscow', timestamptz_выше) — это "покажи мне, который был час / день в данный момент времени в Москве". Результат — "снимок", timestamp. Аналогично и для Лондона.
3. Далее, Вы пытаетесь эти "снимки" вставить в таблицу, где хранятся моменты времени. Для этого нужно преобразовать типы, в процессе преобразования используется time zone сессии (а какая ещё?).

Поэтому и получается такой результат. Т.е. всё это правильно и просто. ;)
код скинул далее. Картинка быстрее доносит информацию, поэтому включил именно её в изначальное сообщение. Ок, в следующий раз буду прикладывать и то, и то, одним сообщением.

Спасибо за пояснение, помогло оформить мысль точнее и найти ответ.

Возвращаясь к оригинальному вопросу, почему timestamptz at time zone возвращает timestamp, а не timestamptz с зоной отображения? Простой ответ, кажется, в том, что тогда пришлось бы где-то хранить эту самую "зону отображения". Соответственно, мой вопрос транслируется в "почему разработчики ПГ решили не хранить таймзону в рамках timestamptz?". Что приводит к этому письму.
То, что хотел бы от ПГ я - это хранение timestamp utc + timezone. Что пытались сделать, но не захотели включать строковое значение в хранение и не смогли (то же письмо) включать не строковое.

Почему я всё это начал. Была база без таймзон, приложению понадобились таймзоны, рассматривал варианты, включая нативные таймзоны ПГ. Из-за того, что timestamptz зону не хранит, а приложению будет говорить, что это время в зоне, установленной на соединении, чтобы избежать непонимания от разработки и необходимости это объяснять, буду, видимо, хранить пару из utc TIMESTAMP и iana_timezone_id CHARACTER VARYING, с ручной конвертацией на приложении и AT TIME ZONE 'utc' AT TIME ZONE iana_timezone_id в скриптах, благо, последних используется значительно меньше.
источник

GB

George Bessonov in pgsql – PostgreSQL
George Bessonov
код скинул далее. Картинка быстрее доносит информацию, поэтому включил именно её в изначальное сообщение. Ок, в следующий раз буду прикладывать и то, и то, одним сообщением.

Спасибо за пояснение, помогло оформить мысль точнее и найти ответ.

Возвращаясь к оригинальному вопросу, почему timestamptz at time zone возвращает timestamp, а не timestamptz с зоной отображения? Простой ответ, кажется, в том, что тогда пришлось бы где-то хранить эту самую "зону отображения". Соответственно, мой вопрос транслируется в "почему разработчики ПГ решили не хранить таймзону в рамках timestamptz?". Что приводит к этому письму.
То, что хотел бы от ПГ я - это хранение timestamp utc + timezone. Что пытались сделать, но не захотели включать строковое значение в хранение и не смогли (то же письмо) включать не строковое.

Почему я всё это начал. Была база без таймзон, приложению понадобились таймзоны, рассматривал варианты, включая нативные таймзоны ПГ. Из-за того, что timestamptz зону не хранит, а приложению будет говорить, что это время в зоне, установленной на соединении, чтобы избежать непонимания от разработки и необходимости это объяснять, буду, видимо, хранить пару из utc TIMESTAMP и iana_timezone_id CHARACTER VARYING, с ручной конвертацией на приложении и AT TIME ZONE 'utc' AT TIME ZONE iana_timezone_id в скриптах, благо, последних используется значительно меньше.
В ответе на вопрос надеялся найти указание на тип/расширение/..., которое реализует честное время с таймзоной или знание, что его нет.
Немного дальнейшего гуглинга привело на https://github.com/mweber26/timestampandtz, но писать поддержку дополнительного формата данных в бинарный протокол для провайдера в мои временные рамки не входит. Может, как-нибудь сделаю это в свободное время
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
George Bessonov
код скинул далее. Картинка быстрее доносит информацию, поэтому включил именно её в изначальное сообщение. Ок, в следующий раз буду прикладывать и то, и то, одним сообщением.

Спасибо за пояснение, помогло оформить мысль точнее и найти ответ.

Возвращаясь к оригинальному вопросу, почему timestamptz at time zone возвращает timestamp, а не timestamptz с зоной отображения? Простой ответ, кажется, в том, что тогда пришлось бы где-то хранить эту самую "зону отображения". Соответственно, мой вопрос транслируется в "почему разработчики ПГ решили не хранить таймзону в рамках timestamptz?". Что приводит к этому письму.
То, что хотел бы от ПГ я - это хранение timestamp utc + timezone. Что пытались сделать, но не захотели включать строковое значение в хранение и не смогли (то же письмо) включать не строковое.

Почему я всё это начал. Была база без таймзон, приложению понадобились таймзоны, рассматривал варианты, включая нативные таймзоны ПГ. Из-за того, что timestamptz зону не хранит, а приложению будет говорить, что это время в зоне, установленной на соединении, чтобы избежать непонимания от разработки и необходимости это объяснять, буду, видимо, хранить пару из utc TIMESTAMP и iana_timezone_id CHARACTER VARYING, с ручной конвертацией на приложении и AT TIME ZONE 'utc' AT TIME ZONE iana_timezone_id в скриптах, благо, последних используется значительно меньше.
> Возвращаясь к оригинальному вопросу, почему timestamptz at time zone возвращает timestamp <skip>

Потому, что реализация была когда-то выполнена в стиле "и нашим, и вашим". Т.е. чтобы и работало, и было на первый взгляд похоже на ISO SQL (который менее чем бесполезен в этом отношении) — а зря, IMHO (надо было нарушать так нарушать — чтобы не было такой путаницы, как сейчас). Поэтому features стандарта, вроде AT TIME ZONE и т.п., использовали, только смысл у них другой. ;)

> мой вопрос транслируется в "почему разработчики ПГ решили не хранить таймзону в рамках timestamptz?

Потому что для хранения моментов времени — это тупо и бесполезно. :)

> То, что хотел бы от ПГ я - это хранение timestamp utc + timezone.

А зачем? Вам, скорее всего, зря кажется, что Вам это нужно.

> не захотели включать строковое значение в хранение и не смогли

Но если Вам действительно нужно, Вы-то можете добавить текстовое поле для time zone.

> чтобы избежать непонимания от разработки и необходимости это объяснять

Если "разработка" не понимает, как правильно работать с timestamp-ами, проблемы у вас вскоре будут куда большие (если данные хоть как-то важны). :(
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
George Bessonov
В ответе на вопрос надеялся найти указание на тип/расширение/..., которое реализует честное время с таймзоной или знание, что его нет.
Немного дальнейшего гуглинга привело на https://github.com/mweber26/timestampandtz, но писать поддержку дополнительного формата данных в бинарный протокол для провайдера в мои временные рамки не входит. Может, как-нибудь сделаю это в свободное время
На кой Вам это нужно, опять-таки? ;)
источник

GB

George Bessonov in pgsql – PostgreSQL
Yaroslav Schekin
На кой Вам это нужно, опять-таки? ;)
приложение работает с авиацией. Прототип был написан под заказчика, летающего в рамках одной ТЗ, в него (зря) не заложили поддержку таймзон. Появился заказчик с маршрутами, пересекающими таймзоны. В авиации принято времена отправления/прибытия отображать в местном времени, для расчёта времени в пути нужно абсолютное время, отсюда и времена с таймзонами - хранить времена отправления/прибытия.
Вариант выводить ТЗ из координат рассматривал, для заведения пунктов он вполне ок, для запросов по пунктам - кажется уже слишком тяжеловесным.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
George Bessonov
приложение работает с авиацией. Прототип был написан под заказчика, летающего в рамках одной ТЗ, в него (зря) не заложили поддержку таймзон. Появился заказчик с маршрутами, пересекающими таймзоны. В авиации принято времена отправления/прибытия отображать в местном времени, для расчёта времени в пути нужно абсолютное время, отсюда и времена с таймзонами - хранить времена отправления/прибытия.
Вариант выводить ТЗ из координат рассматривал, для заведения пунктов он вполне ок, для запросов по пунктам - кажется уже слишком тяжеловесным.
> В авиации принято времена отправления/прибытия отображать в местном времени

Ну так и отображайте, в чём проблема (аэропорты же у вас не переезжают, я надеюсь ;) )?
И их справочник есть? Добавьте туда поле time_zone (с текстовой time zone), и готово.

(Я подобное делал, если что, но не для аэропортов.)
источник

GB

George Bessonov in pgsql – PostgreSQL
Yaroslav Schekin
> В авиации принято времена отправления/прибытия отображать в местном времени

Ну так и отображайте, в чём проблема (аэропорты же у вас не переезжают, я надеюсь ;) )?
И их справочник есть? Добавьте туда поле time_zone (с текстовой time zone), и готово.

(Я подобное делал, если что, но не для аэропортов.)
я так и планирую. Плюс utc TIMESTAMP для пунктов отправления/прибытия. И для фильтров отправления/прибытия, упрощённо,
SELECT '...'
FROM points AS p
INNER JOIN facilities AS f
 USING(facility_id)
WHERE (p.utc AT TIME ZONE 'utc' AT TIME ZONE f.iana_timezone_id)::date = @date
источник

Y

Yury in pgsql – PostgreSQL
Роман Жарков
Именно.
спасибо.
источник

N

Nikolay in pgsql – PostgreSQL
Гость ближайшего Постгрес-вторника (16.06 18:30 мск) — Владимир Бородин, Яндекс.Облако.

Стрим будет тут: https://www.youtube.com/watch?v=ABVhZ8Lg_5g. открыты комментарии и чат, вопросы можно набросать заранее!

Главный док Постгрес-вторников: http://bit.ly/RuPostgresTuesday (там же новая ссылка для активного участия в Zoom).
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
George Bessonov
я так и планирую. Плюс utc TIMESTAMP для пунктов отправления/прибытия. И для фильтров отправления/прибытия, упрощённо,
SELECT '...'
FROM points AS p
INNER JOIN facilities AS f
 USING(facility_id)
WHERE (p.utc AT TIME ZONE 'utc' AT TIME ZONE f.iana_timezone_id)::date = @date
Вы так и не поняли, как это работает, мне кажется... Вам здесь вообще не нужен UTC!
Что-то вроде:
CREATE TABLE airports(
code text NOT NULL PRIMARY KEY,
name text NOT NULL,
time_zone text NOT NULL --  , <прочие поля>
);

CREATE TABLE flights(
-- ...
departure_airport_id REFERENCES airports,
arrival_airport_id REFERENCES airports,
departure_ts timestamptz NOT NULL,
arrival_ts timestamptz NOT NULL
);

И далее что-то вроде:
SELECT f.departure_ts AT TIME ZONE departure_airport.time_zone AS departure_local,
      f.arrival_ts AT TIME ZONE arrival_airport.time_zone AS arrival_local --- , ...
 FROM flights AS f
 JOIN airports AS departure_airport
   ON departure_airport.id = f.departure_airport_id
 JOIN airports AS arrival_airport
   ON arrival_airport.id = f.arrival_airport_id

И всё.
источник

AP

Artyom Poteshkin in pgsql – PostgreSQL
Всем привет. Такой вопрос: "Имеет ли смысл запись NOT NULL DEFAULT 0, или же можно не писать NOT NULL в этом случае?"
источник

П

Павел П. in pgsql – PostgreSQL
Artyom Poteshkin
Всем привет. Такой вопрос: "Имеет ли смысл запись NOT NULL DEFAULT 0, или же можно не писать NOT NULL в этом случае?"
чуть выше обсуждали, с примерами. поиск по этим словам поможет)
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Artyom Poteshkin
Всем привет. Такой вопрос: "Имеет ли смысл запись NOT NULL DEFAULT 0, или же можно не писать NOT NULL в этом случае?"
Вы все сегодня одну лабу что-ли делаете?
источник

AP

Artyom Poteshkin in pgsql – PostgreSQL
Это не лаба, нашел на проекте такую запись, вот решил задать вопрос
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Artyom Poteshkin
Это не лаба, нашел на проекте такую запись, вот решил задать вопрос
Вы все сегодня один проект что-ли нашли?
источник