> Yup, we need to figure out a way of preventing that. I've been thinking
> about adding an attisinherited column to pg_attribute, to mark columns
> that came from a parent table. Such a column could not be renamed or
> dropped except in a command that's recursed from the parent. (But what
> about multiply-inherited columns?)
Many-to-many...
> But you *didn't* make sure it would never be a problem.
Wasn't I looping until I found a unique name?? Dropping a column would
never fail in this case? Adding a column might, but I don't think that's
_impossible_ to avoid.
> > Where would you propose doing these post hoc checks?
>
> Not sure yet. I'm just wondering whether you've found all the places
> that will need to be tweaked to not dump core on nulls in the eref
> lists...
Well have a squiz at the regression test I submitted and see if you can spot
anything. I've attached the latest version of the patch where I've changed
naming to be like you suggested and improved code. Haven't looked at fixing
dependencies yet. I've also fixed foreign keys and the copy command as well
as pg_dump. The only command left is CREATE CONSTRAINT TRIGGER which I have
to hunt down where the heck it actually is implemented.
Even if you decide to change how the commands detect dropped columns (which
I don't think there's terribly much point in doing), it is easy to see from
my patch all the places that need the change.
Chris
