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 the entire test suite (presumably as an option). That should work for physical ordering, but presumably it would pointlessly blow 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 supplied and 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
