On 26.2.2015 23:34, 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.
I agree that committing something without a code that actually uses it in practice is not the best approach. That's one of the reasons why I was asking for the use cases we expect from this. > 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. That's not all that difficult, and can be done in 10 lines of PL/pgSQL - see the attached file. Should be sufficient for development testing (and in production there's not much use for that anyway). >> +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. I think we could calls to the randomization functions into some of the regression tests (say 'create_tables.sql'), but that makes regression tests ... well, random, and I'm not convinced that's a good thing. Also, this makes regression tests harder to think, because "SELECT *" does different things depending on the attlognum order. -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
randomize.sql
Description: application/sql
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
