Re: dblink_build_sql_update versus dropped columns

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: pgsql-hackers@postgreSQL.org
Date: 2010-06-14T18:21:42Z
Lists: pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> On 06/14/2010 10:58 AM, Tom Lane wrote:
>> 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?

Actually, I was working on it myself.  On further reflection I think
that logical numbers are clearly the right thing --- if we define it
as being physical numbers then we will have headaches in the future
when/if we support rearranging columns.  However, there is some small
chance of breaking things in existing DBs if we back-patch that change.
Thoughts?

It strikes me also that the code is not nearly careful enough about
defending itself against garbage input in the primary_key_attnums
argument ...

			regards, tom lane