From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)atentus(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] pg_attribute.attisinherited ? |
Date: | 2002-08-30 19:29:45 |
Message-ID: | 18628.1030735785@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> - Adds a new attribute in pg_attribute named attisinherited.
> - Creation of tables marks it true for attributes that are inherited
> - Addition of new attribute to existing inherited table marks the
> attribute as inherited for child tables.
> - Checked when trying to rename inherited attributes: if table has
> inheritors, only allow renaming if asked to recurse. Disallow
> renaming for child tables only.
> - Checked when trying to drop inherited attributes: if table has
> inheritors, mark attribute as non-inherited for direct inheritors.
> Disallow dropping for child tables only.
I've applied this patch after a little editorializing. FYI ---
* copyfuncs.c,equalfuncs.c,outfuncs.c,readfuncs.c needed to be updated
for the field added to ColumnDef. In general, any time you alter the
definition of a Node structure, you gotta update these files.
* I didn't like having to touch all the callers of TupleDescInitEntry,
so I just made it initialize attisinherited to false. In the one
place where attisinherited might be set true, just update after return
from TupleDescInitEntry.
* Moved the checks for rename/drop ONLY with child tables into
tablecmds.c instead of utility.c, so that they'd be applied after
grabbing an exclusive lock on the table, not before. Otherwise a
child could be added after you look.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-30 19:38:29 | Re: SRF memory mgmt patch (was [HACKERS] Concern about |
Previous Message | Manfred Koizar | 2002-08-30 19:28:18 | Re: source code indexer |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-30 19:38:29 | Re: SRF memory mgmt patch (was [HACKERS] Concern about |
Previous Message | Joe Conway | 2002-08-30 19:05:34 | update to contrib/dblink |