Thread: dblink_build_sql_update versus dropped columns
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
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
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
On 06/14/2010 11:21 AM, Tom Lane wrote: > 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? I didn't even think people were using those functions for many years since I never heard any complaints. I'd say better to not backpatch changes to logical ordering, but FWIW the attached at least fixes the immediate bug in head and ought to work at least a few branches. > It strikes me also that the code is not nearly careful enough about > defending itself against garbage input in the primary_key_attnums > argument ... Probably not :-( Joe
Attachment
Joe Conway <mail@joeconway.com> writes: > I didn't even think people were using those functions for many years > since I never heard any complaints. I'd say better to not backpatch > changes to logical ordering, but FWIW the attached at least fixes the > immediate bug in head and ought to work at least a few branches. [squint...] This doesn't appear to me to fix the problem. You really need the query-construction loops to track logical and physical numbers separately. regards, tom lane
On 06/14/2010 11:54 AM, Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: >> I didn't even think people were using those functions for many years >> since I never heard any complaints. I'd say better to not backpatch >> changes to logical ordering, but FWIW the attached at least fixes the >> immediate bug in head and ought to work at least a few branches. > > [squint...] This doesn't appear to me to fix the problem. You really > need the query-construction loops to track logical and physical numbers > separately. Hmmm, worked for the provided case, but this is a good example of why I *usually* don't send a patch to the list without spending more quality time thinking about the problem ;-) Joe