Re: dblink_build_sql_update versus dropped columns

On 06/14/2010 10:58 AM, Tom Lane wrote:
> 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.

Yup, was just looking at that...

> 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.

Yes, it uses physical attnums, mainly because it was originally written
before we even supported dropped columns and never changed/fixed it.

> 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?

Probably it should be changed to deal with dropped columns correctly,
but I won't have time to look at this closely until the end of the month
-- is that soon enough?

Thanks,

Joe