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.
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.
> +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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
