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