> Philip Warner <[EMAIL PROTECTED]> writes:
> > I think any deisgn needs to cater for attr dependencies. eg.
>
> I don't really see a need to recognize dependencies at finer than table
> level. I'd just make the dependency be from view_a to a and keep things
> simple. What's so wrong with recompiling the view for *every* change
> of the underlying table?
What about other objects. Foreign keys? Serial?
> We could support attr-level dependencies within the proposed pg_depend
> layout if we made pg_attribute one of the allowed object categories.
> However, I'd prefer not to make OID of pg_attribute rows be a primary
> key for that table (in the long run I'd like to not assign OIDs at all
> to pg_attribute, as well as other tables that don't need OIDs). So the
> better way to do it would be to make the pg_depend entries include
> attribute numbers. But I really think this is unnecessary complexity.
I liked the pg_attribute references for some uses. I agree doing that
for a view seems overly complex.
I don't see any value in dropping oid from pg_attribute.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
