On 26.2.2015 23:36, Tom Lane wrote: > Jim Nasby <jim.na...@bluetreble.com> writes: >> On 2/26/15 4:01 PM, Alvaro Herrera wrote: >>> Josh Berkus wrote: >>>> Oh, I didn't realize there weren't commands to change the LCO. Without >>>> at least SQL syntax for LCO, I don't see why we'd take it; this sounds >>>> more like a WIP patch. > >>> 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. > >> +1. This patch is already several years old; lets not delay it further. > > I tend to agree with that, but how are we going to test things if there's > no mechanism to create a table in which the orderings are different?
Physical or logical orderings? Physical ordering is still determined by the CREATE TABLE command, so you can do either CREATE TABLE order_1 ( a INT, b INT ); or (to get the reverse order) CREATE TABLE order_2 ( b INT, a INT ); Logical ordering may be updated directly in pg_attribute catalog, by tweaking the attlognum column UPDATE pg_attribute SET attlognum = 10 WHERE attrelid = 'order_1'::regclass AND attname = 'a'; Of course, this does not handle duplicities, ranges and such, so that needs to be done manually. But I think inventing something like ALTER TABLE order_1 ALTER COLUMN a SET lognum = 11; should be straightforward. But IMHO getting the internals working properly first is more important. -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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