Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > OK, I've been looking at Hiroshi's implementation. It's basically
> > semantically equivalent to mine from what I can see so far. The only
> > difference really is in how the dropped columns are marked.
>
> True enough, but that's not a trivial difference. The problem with
> Hiroshi's implementation is that there's no longer a close tie between
> pg_attribute.attnum and physical positions of datums in tuples. I think
> that that's going to affect a lot of low-level code, and that he hasn't
> found all of it.
Isn't that only for the dropped column. Don't the remaining columns stay
logically clear as far as the tuple storage is concerned?
>
> Keeping the attisdropped marker separate from attnum is logically
> cleaner, and IMHO much less likely to lead to trouble down the road.
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.
> 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.
I honestly don't understand the priorities we are setting here.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026