From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Column storage positions |
Date: | 2007-02-22 06:37:50 |
Message-ID: | 6843.1172126270@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 :-(
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
From | Date | Subject | |
---|---|---|---|
Next Message | Warren Turkal | 2007-02-22 07:03:22 | infinity and DATE type |
Previous Message | Greg Smith | 2007-02-22 04:46:32 | Re: WIP patch - INSERT-able log statements |