Re: Column storage positions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Column storage positions
Date
Msg-id 6843.1172126270@sss.pgh.pa.us
Whole thread Raw
In response to Re: Column storage positions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Column storage positions  ("Phil Currier" <pcurrier@gmail.com>)
List pgsql-hackers
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 :-(

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Log levels for checkpoint/bgwriter monitoring
Next
From: Warren Turkal
Date:
Subject: infinity and DATE type