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
signature.asc
Description: OpenPGP digital signature
