Re: DROP VIEW code question

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