On 2/26/15 4:34 PM, Andres Freund wrote:
> On 2015-02-26 16:16:54 -0600, Jim Nasby wrote:
>> On 2/26/15 4:01 PM, Alvaro Herrera wrote:
>>> The reason for doing it this way is that changing the underlying
>>> architecture is really hard, without having to bear an endless hackers
>>> bike shed discussion about the best userland syntax to use. It seems a
>>> much better approach to do the actually difficult part first, then let
>>> the rest to be argued to death by others and let those others do the
>>> easy part (and take all the credit along with that); that way, that
>>> discussion does not kill other possible uses that the new architecture
>>> allows.
>
> I agree that it's a sane order of developing things. But: I don't think
> it makes sense to commit it without the capability to change the
> order. Not so much because it'll not serve a purpose at that point, but
> rather because it'll essentially untestable. And this is a patch that
> needs a fair amount of changes, both automated, and manual.
It's targeted for 9.6 anyway, so we have a while to decide on what's
committed when. It's possible that there's no huge debate on the syntax.
> At least during development I'd even add a function that randomizes the
> physical order of columns, and keeps the logical one. Running the
> regression tests that way seems likely to catch a fair number of bugs.
Yeah, I've thought that would be a necessary part of testing. Not really
sure how we'd go about it with existing framework though...
>> +1. This patch is already several years old; lets not delay it further.
>>
>> Plus, I suspect that you could hack the catalog directly if you really
>> wanted to change LCO. Worst case you could create a C function to do it.
>
> I don't think that's sufficient for testing purposes. Not only for the
> patch itself, but also for getting it right in new code.
We'll want to do testing that it doesn't make sense for the API to
support. For example, randomizing the storage ordering; that's not a
sane use case. Ideally we wouldn't even expose physical ordering because
the code would be smart enough to figure it out.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
