From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | mhh(at)mindspring(dot)com |
Cc: | hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP VIEW code question |
Date: | 2000-10-17 20:33:20 |
Message-ID: | 2181.971814800@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-17 20:43:41 | Re: DROP VIEW code question |
Previous Message | Peter Eisentraut | 2000-10-17 20:33:07 | Re: DROP VIEW code question |