Re: dblink_build_sql_update versus dropped columns - Mailing list pgsql-hackers

From Tom Lane
Subject Re: dblink_build_sql_update versus dropped columns
Date
Msg-id 16683.1276539702@sss.pgh.pa.us
Whole thread Raw
In response to Re: dblink_build_sql_update versus dropped columns  (Joe Conway <mail@joeconway.com>)
Responses Re: dblink_build_sql_update versus dropped columns
List 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


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: dblink_build_sql_update versus dropped columns
Next
From: Josh Berkus
Date:
Subject: Re: GSoC - Materialized Views - is stale or fresh?