On 05/25/2017 05:24 PM, Tom Lane wrote: > Vik Fearing <vik.fear...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
