Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Дата
Msg-id CAMsGm5cKaagUMUOAHuihgt=CV2NhrfDAZvGkggBOEwy3O4KqBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Peter Moser <pitiz29a@gmail.com>)
Список pgsql-hackers
On 28 June 2018 at 05:37, Peter Moser <pitiz29a@gmail.com> wrote:
[....] 
In general my use-case is, that I want to delete an X in a certain namespace, where the type is not known in advance. I could query the catalog to get that information and then build a procedure to "execute" the right DROP command (as Pavel Stehule suggested), but that adds complexity to the application code, where it shouldn't be necessary IMHO.

I've dealt with this issue in some contexts by writing a procedure which takes a regclass parameter and formats and executes an appropriate "DROP [x]" command.

On a related note, I sometimes find myself wanting to drop a bunch of tables and views and I find it inconvenient that I have to split up my drop into two commands - one for the views and one for the tables.

This is a vote for a "DROP RELATION" command that doesn't care if the objects are views, materialized views, tables, or a mix of those. Maybe even index or sequence or the other possible values of pg_class.relkind, although I don't normally think of those as relations.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yugo Nagata
Дата:
Сообщение: Fix to not check included columns in ANALYZE on indexes
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: SCRAM with channel binding downgrade attack