Re: Renaming a table to an array's autogenerated name

Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> writes:
> In commit 9aa3c782c93, Tom fixed a bug in which creating a table _foo
> when an array type of that name already existed would make the array
> type change its name to get out of the way. But it missed a trick in
> that renaming a table would still cause a conflict.

Good catch.

> One interesting thing to note however, is that if you rename a table to
> its own array's name (which was my case when I found this bug), the new
> array name will be ___foo instead of just __foo. I don't know if it's
> worth worrying about that.

This seemed weird to me. Stepping through the logic, I see that what's
happening is that the moveArrayTypeName call you added renames the
array type from "_foo" to "__foo", and then at the bottom of
RenameTypeInternal we call makeArrayTypeName/RenameTypeInternal again
on that array type. makeArrayTypeName sees that "__foo" exists and
assumes the name is in use, even though it's really this same type and
no more renaming is needed. So it ends up picking the next choice
"___foo".

After some experimentation, I came up with the attached, which simply
skips the "recursive" step if it would apply to the same array type we
already moved.

I added some queries to the regression test case to show exactly what
happens to the array type names, and in that, you can see that the
behavior for the "normal" case with distinct array types is that neither
array type ends up with a name that is just the unsurprising case of
an underscore followed by its element type's name; they *both* have an
extra underscore compared to that. Maybe that's okay. We could possibly
rejigger the order of renaming so that one of them ends with an
unsurprising name, but I failed to make that happen without considerably
more surgery.

regards, tom lane