If the first statement doesn't fail, then the second statement will be successful with very high priority. For me is little bit more intuitive message "cannot to drop some" then "cannot to create some" when first command is DROP, and I have to investigate, why DROP was ignored.
Fixing this bug you’d still get: Error: cannot create table xxx, view with same name already exists. Do you seriously expect a user to then ask why the drop table command didn’t tell them about the view with the same name?
The create command should deal with namespace sharing, the drop command just should do what is written on the tin. Especially since that is all it is documented to be concerned with. As demonstrated actual use cases are broken with the current behavior which exists seemingly to only try and reduce user confusion. I’d rather have the defined and expected behavior here and deal with confused people on the mailing list then tell people on their valid uses are not as important.
If we change the behaviour then other group of users will be confused in other cases. For me - this case is ambiguous, and the change doesn't do things better for all.
I try to think about it from a different perspective and I don't see any result. Minimally
postgres=# create table xxx (a int); CREATE TABLE postgres=# drop view xxx; ERROR: "xxx" is not a view HINT: Use DROP TABLE to remove a table.
DROP TABLE IF EXISTS and DROP TABLE are consistent now. The message is ""xxx" is not a view", it is not ""xxx" doesn't exist".
I would like to see the opinions of other people. I don't see "fixing this case" as a clean win. I see the benefits and disadvantages.