On Tuesday 17 October 2000 16:33, Tom Lane wrote:
> 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.
Yes, prior to the separate relkind for views, it was necessary for that.
I just didn't see a need now.
>
> > 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 ...
Ok.
--
Mark Hollomon
