Horton
Menu

Thread

  1. dblink_build_sql_update versus dropped columns

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-06-14T17:58:06Z

    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

  2. Re: dblink_build_sql_update versus dropped columns

    Joe Conway <mail@joeconway.com> — 2010-06-14T18:05:54Z

    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

  3. Re: dblink_build_sql_update versus dropped columns

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-06-14T18:21:42Z

    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

  4. Re: dblink_build_sql_update versus dropped columns

    Joe Conway <mail@joeconway.com> — 2010-06-14T18:47:26Z

    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

  5. Re: dblink_build_sql_update versus dropped columns

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-06-14T18:54:57Z

    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

  6. Re: dblink_build_sql_update versus dropped columns

    Joe Conway <mail@joeconway.com> — 2010-06-14T18:58:49Z

    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