Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Date
Msg-id CAMsGm5cKaagUMUOAHuihgt=CV2NhrfDAZvGkggBOEwy3O4KqBQ@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS  (Peter Moser <pitiz29a@gmail.com>)
List 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 by date:

Previous
From: Yugo Nagata
Date:
Subject: Fix to not check included columns in ANALYZE on indexes
Next
From: Bruce Momjian
Date:
Subject: Re: SCRAM with channel binding downgrade attack