From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Phil Currier <pcurrier(at)gmail(dot)com> |
Subject: | Re: logical column ordering |
Date: | 2014-12-09 23:00:31 |
Message-ID: | 54877F0F.2020800@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-12-09 23:06:04 | Re: operator does not exist: character varying[] <> character[] |
Previous Message | Stephen Frost | 2014-12-09 22:40:35 | Re: GSSAPI, SSPI - include_realm default |