On 05/26/2017 03:20 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 05/25/2017 05:24 PM, Tom Lane wrote:
>>> 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
Vik Fearing writes:
> On 05/25/2017 05:24 PM, Tom Lane wrote:
>> 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.
Pushed, thanks for reviewing.
On 05/25/2017 05:24 PM, Tom Lane wrote:
> Vik Fearing 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
Vik Fearing 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 catc
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.
Steps to reproduce:
postgres=# create
