On 12/9/14, 11:41 AM, Alvaro Herrera wrote:
> I'm going to see about it while I get feedback on the rest of this patch; in
> particular, extra test cases that fail to work when columns have been
> moved around are welcome, so that I can add them to the regress test.
> What I have now is the basics I'm building as I go along. The
> regression tests show examples of some logical column renumbering (which
> can be done after the table already contains some data) but none of
> physical column renumbering (which can only be done when the table is
> completely empty.) My hunch is that the sample foo, bar, baz, quux
> tables should present plenty of opportunities to display brokenness in
> the planner and executor.
The ideal case would be to do something like randomizing logical and physical ordering as tables are created throughout
theentire test suite (presumably as an option). That should work for physical ordering, but presumably it would
pointlesslyblow up on logical ordering because the expected output is hard-coded.
Perhaps instead of randomizing logical ordering we could force that to be the same ordering in which fields were
suppliedand actually randomize attnum?
In particular, I'm thinking that in DefineRelation we can randomize stmt->tableElts before merging in inheritance
attributes.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com