Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On 28 June 2018 at 05:37, Peter Moser <pitiz29a(at)gmail(dot)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.