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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
