On 05/25/2017 05:24 PM, Tom Lane wrote:
> Vik Fearing <vik.fearing@2ndquadrant.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.
>
> 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.
This looks good to me.
> 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.
I don't think this really matters to anyone in practice, so I'm fine
with it.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
