Thread: Re: [PATCHES] Demo patch for DROP COLUMN

> 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

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> But you *didn't* make sure it would never be a problem.

> Wasn't I looping until I found a unique name?

My point was that there could still be a conflict against a user column
that the user tries to create *later*.  So it's illusory to think that
making the name of a dropped column less predictable will improve
matters.
        regards, tom lane

On Tue, 2002-07-23 at 20:42, Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> >> But you *didn't* make sure it would never be a problem.
> 
> > Wasn't I looping until I found a unique name?
> 
> My point was that there could still be a conflict against a user column
> that the user tries to create *later*.  So it's illusory to think that
> making the name of a dropped column less predictable will improve
> matters.

The simple (to describe, perhaps not to implement ;) way to resolve it
would be for the ADD COLUMN (or CREATE TABLE INHERITS) rename the
offending deleted column once more.

--------------
Hannu

> > My point was that there could still be a conflict against a user column
> > that the user tries to create *later*.  So it's illusory to think that
> > making the name of a dropped column less predictable will improve
> > matters.
> 
> The simple (to describe, perhaps not to implement ;) way to resolve it
> would be for the ADD COLUMN (or CREATE TABLE INHERITS) rename the
> offending deleted column once more.

Hah! What a wonderful idea!  Now why didn't I think of that!

Chris