Re: Demo patch for DROP COLUMN

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> What's broken about it? RENAME probably is broken, in that it should
>> never allow non-recursion, but DROP doesn't have that issue.

> Hrm. Yeah I guess the real problem is dropping a column that still exists
> in an ancestor. I got mixed up there.

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?)

> Is there a problem with this,
> though:
> ALTER TABLE ONLY ancestor DROP a;
> Seems a little dodgy to me...

Seems okay to me. The columns in the children would cease to be
inherited and would become plain columns. That might mean going
around and marking them so, if we adopt an explicit marking.

>> the hack above only avoids half of the problem, namely when the
>> user column already exists.

> Problem was, I couldn't find a generated name that was _impossible_ to enter
> as a user. So, I made sure it would never be a problem.

But you *didn't* make sure it would never be a problem.

> Well, that change was actually trivial after I thought it was going to be
> difficult... When you say "after getting a match need to check if actually
> valid", wasn't that what I proposed originally,

No, your original code tested for validity before the strcmp, which is
surely the slowest possible way to do things.

> 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...

regards, tom lane