Re: Column storage positions - Mailing list pgsql-hackers

On Thursday 22 February 2007 09:06, Phil Currier wrote:
> On 2/22/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andrew Dunstan <andrew@dunslane.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.
>

Can you post a patch of what you have now to -patches? 

> 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.
>

Are you that opposed to working on the display portions as well?  You'll be a 
hero to thousands of mysql users if you do it. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL