Re: Column storage positions

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

In response to

Responses

Browse pgsql-hackers by date

  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