On 26.2.2015 23:36, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@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
