Tom Lane wrote:
>It's completely fallacious to imagine that we could make this change be
>transparent to external applications. To take two examples:
>
>1. How many places do you think know that pg_attribute.attnum links to
>pg_attrdef.adnum? pg_dump, psql, and the JDBC driver all appear to
>know that, in a quick search of the CVS tree; I haven't even bothered to
>look at pgadmin and the other apps that are likely to have such
>dependencies.
>
>2. How about linking pg_attribute.attnum to entries in pg_index.indkey?
>Lots of apps know about that too.
>
>Unless you are going to change the meanings of pg_index.indkey and
>pg_attrdef.adnum, you can't simply redefine attnum as a logical column
>position. And if you do make such a change you will break code
>elsewhere.
>
>If we add a *new* column attlogpos, without changing the semantics
>of attnum, then I think we have a fighting chance of making this work
>without an undue amount of effort. I see no prospect that we can
>change the meaning of attnum without breaking things far and wide.
>
>
>
I don't quite understand your argumentation.
Currently, attnum is used
1) to determine position (the concern)
2) as part of the unique identifier, as used by index, FK etc
3) as pointer for data retrieval.
If only the retrieval functions would use attstoragenum or however you'd
call it, all other references to attnum can remain untouched. Actual
physical reordering would be hidden almost completely. This is a bit
like abstracting a primary key from the row's physical storage location.
Regards,
Andreas
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>
>
