|
Как обнаружить зависимость view от constraint?
|
|||
---|---|---|---|
#18+
Добрый день! Создаю таблицу, имеющую ограничение в виде первичного ключа: Код: sql 1. 2.
Потом создаю представление, основанное на этой таблице. Важный момент - в представлении используется группировка по первичному ключу исходной таблицы: Код: sql 1.
В таблице pg_constraint появляется одна запись об ограничении, относящаяся к таблице t_table: Код: sql 1. 2. 3. 4. 5.
Если я пытаюсь удалить это ограничение из таблицы, то Postgres мне сообщает, что представление t_view зависит от этого же ограничения: Код: sql 1. 2. 3. 4.
Подскажите, пожалуйста, в каких объектах системного каталога можно увидеть связь между t_view и t_table_pkey? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:53 |
|
Как обнаружить зависимость view от constraint?
|
|||
---|---|---|---|
#18+
Зависимости между объектами хранятся в pg_depend . Если поколдовать с запросами к этой таблице, то можно найти, что от ограничения t_table_pkey зависит правило перезаписи в pg_rewrite. Это правило перезаписи является правилом ON SELECT для представления t_view и в свою очередь зависит от самого представления. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 10:22 |
|
Как обнаружить зависимость view от constraint?
|
|||
---|---|---|---|
#18+
Павел Лузанов, спасибо, поколдую! Экспериментируя с созданием представлений на основе таблицы t_table, обнаружил, что если представление будет создано без группировки по первичному ключу исходной таблицы: Код: sql 1.
, то ограничение удаляется без проблем: Код: sql 1. 2.
Почему GROUP BY во view создаёт зависимость между ограничением таблицы и представлением? Получается, что в случае отсутствия в таблице CONSTRAINT'а на основе PRIMARY KEY, процесс группировки, в ходе наполнения view данными, мог бы столкнуться с неуникальными значениями в столбце id? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2021, 09:48 |
|
Как обнаружить зависимость view от constraint?
|
|||
---|---|---|---|
#18+
Вот что получается. Код: sql 1.
На мой взгляд, постгрес имеет полное право не создавать представление в таком виде, а просто выдать ошибку. Ведь столбец part_number не может входить в список SELECT не находясь в GROUP BY. В списке SELECT к нему нужно обязательно групповую функцию применять. Попробуйте выполнить запрос отдельно. Но постгрес догадался, что группировка выполняется по столбцу первичного ключа, т.е. по сути группировка не нужна. Ведь если все значения id уникальные, то и группировать нечего. А это значит что запрос можно выполнить и в таком виде, но нужно быть уверенным, что id всегда уникальные. Такую уверенность реализовали через зависимость представления от ограничения первичного ключа. Пока ограничение есть, можно обращаться к представлению. Но зачем выполнять GROUP BY по столбцу первичного ключа - это вопрос не к постгресу, а к авторам запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2021, 11:31 |
|
|
start [/forum/topic.php?fid=53&msg=40057711&tid=1994117]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 256ms |
total: | 382ms |
0 / 0 |