Re: DROP VIEW code question

On Tuesday 17 October 2000 16:33, Tom Lane wrote:
> Mark Hollomon <mhh(at)mindspring(dot)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