> 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
dropcolumn3.txt.gz
Description: GNU Zip compressed data
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
