Size: a a a

pgsql – PostgreSQL

2020 June 15

РЖ

Роман Жарков... in pgsql – PostgreSQL
Yury
всем привет. Кто может дать ссылку или объяснить как работает связка
alter table Defalut SET DEFAULT  value
alter table Defalut SET NOT NULL

Нет ли тут избыточности?
По мне просто вторая строка оверхэд.
Это вообще про разное.
источник

Y

Yury in pgsql – PostgreSQL
Роман Жарков
Это вообще про разное.
понятно что про разное. Но если придет NULL, то в поле засетится дефолтное значение. Разве не так?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
George Bessonov
я (кажется) понимаю, как работают таймзоны в ПГ (хранится UTC, выводится в указанной или дефолтной для соединения/пользователя/базы/сервера). Я вижу, что сравнение времён с явным указанием разных таймзон сравнивает выводимые значения (с применёнными таймзонами), а не значения UTC. Я понимаю, что сравнение пройдёт корректно, если не указывать таймзоны явно. Мне интересно, почему сделали, чтобы при явном указании таймзон сравнивались значения с применёнными таймзонами
> я (кажется) понимаю, как работают таймзоны в ПГ (хранится UTC

Неважно, что там хранится (UTC или нет) — забудьте об этом, это только мешает пониманию, IMHO.
Важно то, что timestamp with time zone хранит момент на шкале "абсолютного" времени (т.е. никаких time zone, лет и дней там, естественно, нет), а timestamp without time zone — это просто "фотография" календаря и часов, которая сама по себе никакого момента времени не представляет (соответствующих моментов может быть десятки — зависит от того, в каком часовом поясе / DST был сделан этот "снимок").
А "AT TIME ZONE" переводит одно в другое, см. документацию.
Т.е. поведение PostgreSQL тут вообще правильное... только названия странные (но за это спасибо ISO SQL). ;)
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Yury
понятно что про разное. Но если придет NULL, то в поле засетится дефолтное значение. Разве не так?
Нет, не так. Первое делает умолчание при вставке записи, а второе запрещает явную установку NULL.
источник

4

4g in pgsql – PostgreSQL
Yury
понятно что про разное. Но если придет NULL, то в поле засетится дефолтное значение. Разве не так?
если я не ошибаюсь, то если прилетает NULL и установлено DEFAULT value применяется DEFAULT value, а вот если DEFAULT value не установлен в поле запишется null
источник

Y

Yury in pgsql – PostgreSQL
Роман Жарков
Нет, не так. Первое делает умолчание при вставке записи, а второе запрещает явную установку NULL.
на апдейт сработает вторая запись, получается. Если придет NULL? Я правильно понял? При инсерте буде ставлен дефлот
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
4g
если я не ошибаюсь, то если прилетает NULL и установлено DEFAULT value применяется DEFAULT value, а вот если DEFAULT value не установлен в поле запишется null
test=# create table test ( some_data varchar default 'hehehe' );
CREATE TABLE
test=# insert into test default values;
INSERT 0 1
test=# insert into test values ( 'gygygy' );
INSERT 0 1
test=# select * from test;
some_data
-----------
hehehe
gygygy
(2 rows)

test=# insert into test values ( NULL );
INSERT 0 1
test=# select * from test;
some_data
-----------
hehehe
gygygy

(3 rows)

test=#
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Yury
на апдейт сработает вторая запись, получается. Если придет NULL? Я правильно понял? При инсерте буде ставлен дефлот
test=# alter table test alter column some_data set not null;
ERROR:  column "some_data" contains null values
test=# delete from test where some_data is null;
DELETE 1
test=# alter table test alter column some_data set not null;
ALTER TABLE
test=# insert into test values ( NULL );
ERROR:  null value in column "some_data" violates not-null constraint
DETAIL:  Failing row contains (null).
test=#
источник

4

4g in pgsql – PostgreSQL
Роман Жарков
test=# create table test ( some_data varchar default 'hehehe' );
CREATE TABLE
test=# insert into test default values;
INSERT 0 1
test=# insert into test values ( 'gygygy' );
INSERT 0 1
test=# select * from test;
some_data
-----------
hehehe
gygygy
(2 rows)

test=# insert into test values ( NULL );
INSERT 0 1
test=# select * from test;
some_data
-----------
hehehe
gygygy

(3 rows)

test=#
мое сообщение подразумевало установленный флаг not null в поле
если такого флага нет, то конечно запишется то что было передано
источник

GB

George Bessonov in pgsql – PostgreSQL
Yaroslav Schekin
> я (кажется) понимаю, как работают таймзоны в ПГ (хранится UTC

Неважно, что там хранится (UTC или нет) — забудьте об этом, это только мешает пониманию, IMHO.
Важно то, что timestamp with time zone хранит момент на шкале "абсолютного" времени (т.е. никаких time zone, лет и дней там, естественно, нет), а timestamp without time zone — это просто "фотография" календаря и часов, которая сама по себе никакого момента времени не представляет (соответствующих моментов может быть десятки — зависит от того, в каком часовом поясе / DST был сделан этот "снимок").
А "AT TIME ZONE" переводит одно в другое, см. документацию.
Т.е. поведение PostgreSQL тут вообще правильное... только названия странные (но за это спасибо ISO SQL). ;)
ок, хранится абсолютное время.
Почему тогда этот код говорит, что gt: true? В моём понимании, информация о таймзонах должна была обрезаться на вставке и храниться должно было абсолютное время (2020-06-11 08:28:27), вывод должен был быть eq: true, a и b при этом - выводиться в ТЗ соединения (а выводятся в ТЗ вставки)
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
4g
мое сообщение подразумевало установленный флаг not null в поле
если такого флага нет, то конечно запишется то что было передано
см. следующий мой пример.
источник

GB

George Bessonov in pgsql – PostgreSQL
George Bessonov
ок, хранится абсолютное время.
Почему тогда этот код говорит, что gt: true? В моём понимании, информация о таймзонах должна была обрезаться на вставке и храниться должно было абсолютное время (2020-06-11 08:28:27), вывод должен был быть eq: true, a и b при этом - выводиться в ТЗ соединения (а выводятся в ТЗ вставки)
источник

4

4g in pgsql – PostgreSQL
Роман Жарков
см. следующий мой пример.
т.е. если мы явно передадим null вызовет ошибку, не смотря на то что есть default value?
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
4g
т.е. если мы явно передадим null вызовет ошибку, не смотря на то что есть default value?
Именно.
источник

4

4g in pgsql – PostgreSQL
Роман Жарков
Именно.
кхм... надо запомнить, спасибо!
источник

Т

Т.А in pgsql – PostgreSQL
в настройках поменял порт, но всё равно слушает 6432
источник

Т

Т.А in pgsql – PostgreSQL
источник

Т

Т.А in pgsql – PostgreSQL
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
George Bessonov
ок, хранится абсолютное время.
Почему тогда этот код говорит, что gt: true? В моём понимании, информация о таймзонах должна была обрезаться на вставке и храниться должно было абсолютное время (2020-06-11 08:28:27), вывод должен был быть eq: true, a и b при этом - выводиться в ТЗ соединения (а выводятся в ТЗ вставки)
Тут никакого кода нет, только какая-то картинка.

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

Странно... вроде бы, в документации были объяснения, с примерами...
Ладно, по шагам:
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 сессии (а какая ещё?).

Поэтому и получается такой результат. Т.е. всё это правильно и просто. ;)
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Вот сразу бы так. ;)
источник