Re: DROP VIEW code question

Mark Hollomon <mhh@mindspring.com> writes:
> In tcop/ulitity.c we have the following code fragment:
> case VIEW:
> {
>     char       *viewName = stmt->name;
>     char       *ruleName;

>     ruleName = MakeRetrieveViewRuleName(viewName);
>     relationName = RewriteGetRuleEventRel(ruleName);

> This looks like an expensive no-op to me.
> if viewname == "myview"
> then ruleName == "_RETmyview" (+/- multibyte aware truncation)
> then relationName == "myview"

> Is this code doing something that I'm missing?

It's probably done that way for symmetry with the DROP RULE case.
I don't see any big need to change it --- DROP VIEW is hardly a
performance-critical path.  And it *does* help ensure that what
you are dropping is a view not a plain table.

> Also
> "DROP TABLE x, y, z" is allowed, but
> "DROP VIEW x, y, z" is not.
> Any reason other than historical?

No, not that I can think of.  If you want to fix that, go for it.
You might consider merging DropStmt and RemoveStmt into one parsenode
type that has both a list and an object-type field.   I see no real
good reason why they're separate ...
        regards, tom lane