From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sorting table columns |
Date: | 2011-12-21 01:23:36 |
Message-ID: | 23156.1324430616@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of mar dic 20 18:24:29 -0300 2011:
>> You do *not* want to store either of the latter two numbers in
>> parse-time Var nodes, because then you can't rearrange columns without
>> having to update stored rules. But it might be useful to decree that
>> one thing setrefs.c does is renumber Vars in scan nodes to use the
>> physical column numbers instead of the permanent IDs.
> Hmm, having the numbers in Var nodes seems a fundamental part of the way
> I'm attacking the problem. Hopefully after I give setrefs.c a read I
> will have a clearer picture of the way to do it without that.
To clarify a bit: one thing that setrefs.c already does is to renumber
Var nodes above the scan level, so that their attnums refer not to
original table column attnums but to column numbers in the output of the
next plan level down. Vars in scan nodes currently don't need any
renumbering, but it'd be easy enough to extend the logic to do something
to them as well. I'm visualizing the run-time transformation from
physical to logical column ordering as a sort of projection, much like
the mapping that happens in a join node.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-12-21 02:04:29 | Re: JSON for PG 9.2 |
Previous Message | Noah Misch | 2011-12-21 01:14:43 | Re: RangeVarGetRelid() |