> 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.
OK, I can see how that would be a problem actually. You'd have to regard
attnum as a 'virtual attnum' and keep having to reverse the computation to
figure out what its original attnum was...
> Keeping the attisdropped marker separate from attnum is logically
> cleaner, and IMHO much less likely to lead to trouble down the road.
I'm a purist and I like to think that good, clean, well thought out code
always results in more stable, bug free software.
> 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.
It's also not 'every client app' that will need to be altered. Just DB
admin apps, of which there aren't really that many. And remember, anyone
who uses the catalogs directly always does so at their own risk. I think
that once we have a proper INFORMATION_SCHEMA anyway, all clients should use
that. Heck, if INFORMATION_SCHEMA gets in in 7.3, then clients might have a
_heap_ of work to do...
Chris