Предположим, у меня есть следующая таблица:
CREATE TABLE tags (
id int PK,
name varchar(255),
CONSTRAINT name_unique UNIQUE(name)
)
Мне нужен запрос, который будет вставлять теги, которые не существуют, и возвращать идентификаторы для всех запрошенных тегов. Рассмотрим следующее:
INSERT INTO tags (name) values ('tag10'), ('tag6'), ('tag11') ON CONFLICT DO NOTHING returning id, name
Результат этого запроса:
+---------------+
| id | name |
|---------------|
| 208 | tag10 |
|---------------|
| 209 | tag11 |
+---------------+
Мне нужно, чтобы на выходе было tag6
.
varchar(255)
, более эффективным, чем столбец, определенный какvarchar(300)
. Каждый раз, когда я вижу это магическое число 255, я задаюсь вопросом, почему оно было выбрано — особенно с Postgres, где нет абсолютно никакой разницы в производительности междуvarchar(1)
, varchar(78656)` иtext
(когда вы сохраняете только один символ). Вы должны рассматривать определение длины как бизнес-ограничение, а не как техническую вещь. - person a_horse_with_no_name   schedule 08.02.2016varchar(255)
происходит от Oracle. (Кажется, я припоминаю, что меньшие столбцы varchar в Postgres не поджариваются) - person joop   schedule 08.02.2016varchar(255)
(по крайней мере, с 8i). И решение о тосте (= сжатии) значения в Postgres принимается не на основе столбца definition, а на фактической длине хранящегося там значения. - person a_horse_with_no_name   schedule 08.02.2016