> > What's your point? No client that examines pg_attribute can be trusted
> > until it's been examined pretty closely (as in, more closely than
> > Christopher looked at pg_dump). I'd prefer to see us keep the backend
> > simple and trustworthy, rather than pursue a largely-illusory idea that
> > we might be saving some trouble on the client side. The clients are
> > less likely to cause unrecoverable data corruption if something is
> > missed.
I'm prepared to admit I didn't look at pg_dump too hard. I have to say that
I agree with Tom here, but that's personal opinion. If Tom reckons that
there's places where Hiroshi's implementation needed work and that there
would be messiness, then I'm inclined to believe him.
In all honesty, the amount of changes clients have to make to support
schemas makes checking dropped columns pale in significance.
> > If we were willing to remap attnums so that clients would require *no*
> > changes, it would be worth doing --- but I believe we've already
> > rejected that approach as unworkable. I don't think "maybe you don't
> > need to change, but you'd better study your code very carefully anyway"
> > is a big selling point.
Exactly. I like the whole 'explicit' idea of having attisdropped. There's
no ifs and buts. It's not a case of, "oh, the attnum is negative, but it's
not an arbitratily negative system column" sort of thing.
> I will vote for the option that has the less pain for our users _and_ in
> the backend, but if it is close, I will prefer to make things easier on
> clients/users.
I will vote for attisdropped. However, I'm not a main developer and I will
go with the flow. In the meantime, I'm developing attisdropped but using
some of Hiroshi's implementation...
Chris
