Re: BETWEEN Node & DROP COLUMN

> My problem is that you are pushing the DROP COLUMN check out into almost
> every client that uses pg_attribute. And we are doing this to keep our
> backend cleaner. Seems we should do the work once, in the backend, and
> not burden clients will all of this.

As a user of Postgres, I found the following more painful:

* Anti-varchar truncation in 7.2
* Making you have to quote "timestamp"(), etc.

People mail the list every day with backwards compatibility problems. We've
done it before, why not do it again? In fact, I'm sure there are already
backwards compatibility problems in 7.3.

> > We should not allow ourselves to put too much weight on the fact that
> > some clients use "attnum > 0" as a filter for attributes that they
> > (think they) need not pay attention to. That's only a historical
> > artifact, and it's far from clear that it will keep those clients
> > out of trouble anyway.
>
> Well, why shouldn't we use the fact that most/all clients don't look at
> attno < 0, and that we have no intention of changing that requirement.
> We aren't coding in a vacuum. We have clients, they do that already,
> let's use it.
>
> Attno < 0 is not historical. It is in the current code, and will remain
> so for the forseeable future, I think.

Problem is, the current code actually assumes that attno < 0 means that the
attribute is a system column, NOT a dropped user column.

As an example, I'd have to change all of these in the Postgres source code:

/* Prevent them from altering a system attribute */
if (attnum < 0)
elog(ERROR, "ALTER TABLE: Cannot alter system attribute
\"%s\"",
colName);

Who knows how many other things like this are littered through the source?

Chris