[HACKERS] dblink_build_sql_update versus dropped columns
in [PgSql]
|
Prev: [HACKERS] Reviewfest 2010-06 Plans and Call for Reviewers
Next: Command Prompt 8.4.4 PRMs compiled withdebug/assert enabled
From: Tom Lane on 14 Jun 2010 13:58 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |