dblink_build_sql_update versus dropped columns

A recent bug report
http://archives.postgresql.org/pgsql-admin/2010-06/msg00101.php
shows that dblink_build_sql_update and friends are really not all there
when it comes to dealing with dropped columns in the target table.
The immediate cause of the reported crash is just an internal matter,
but while looking at it I realized that there is also an API issue:
are the column numbers in the passed-in primary_key_attnums array to be
taken as logical or physical attnums? If the user extracted the array
from a pg_index entry then they are physical attnums, but if he just
writes the array by hand then they are probably logical numbers, ie,
they would not count any dropped columns appearing before the PK
columns.

I suspect the point has never come up before because PKs are commonly
the first columns anyway.

The current effective behavior of the code is that the column numbers
are physical numbers. Should we document it that way, or change it?

regards, tom lane