Re: Column storage positions

On 2/22/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > Alvaro Herrera wrote:
> >> Right, I'm not advocating not doing that -- I'm just saying that the
> >> first step to that could be decoupling physical position with attr id
> >> :-) Logical column ordering (the order in which SELECT * expands to)
> >> seems to me to be a different feature.
>
> > Except in the sense that divorcing the id from the storage order makes
> > it possible to do sanely. :-)
>
> They are different features, but they are going to hit all the same
> code, because the hardest part of this remains making sure that every
> piece of the code is using the right kind of column number. The
> suggestion I posted awhile ago amounts to saying that we might be able
> to solve that by default, by making sure that only one definition of
> "column number" is relevant to the majority of the backend and we can
> figure out exactly where the other definitions need to apply. But
> that's handwaving until someone actually does it :-(

I don't really think it's just handwaving at this point because I've
done a lot of it :). I'm not saying the work is done, or that a lot
more testing isn't required, but at the moment I have a working system
that seems to do what it needs to do to separate storage position from
permanent ID/display position. And the changes to accomplish this
were quite localized - namely the tuple access routines in
heaptuple.c, and the small handful of places that need to construct
tuple descriptors. That's pretty much it - the rest of the codebase
is remains untouched.

> In any case I think it's foolish not to tackle both issues at once.
> We know we'd like to have both features and we know that all the same
> bits of code need to be looked at to implement either.

I guess I disagree with that sentiment. I don't think it's necessary
to bundle these two features together, even if some analysis will be
duplicated between them, since they are completely distinct in a
functional sense and will touch different places in the code.
Smaller, more incremental changes make more sense to me.

But if both-features-at-once is what the community wants, that's fine,
no worries. I'll just pull my own personal hat out of the ring until
someone comes along who's interested in implementing them both at the
same time.

phil