Hi Ashutosh,
On 2017/06/12 20:56, Ashutosh Bapat wrote:
> Hi,
> If we detach a partition and drop the corresponding partitioned table,
> it drops the once-partition now-standalone table as well.
Thanks for the report. Looks like 8b4d582d279d78 missed the bit about
drop_parent_dependency() that you describe in your analysis below.
> The reason for this is as follows
> An AUTO dependency is recorded between a partitioned table and partition. In
> case of inheritance we record a NORMAL dependency between parent
> and child. While
> detaching a partition, we call RemoveInheritance(), which should have taken
> care of removing this dependency. But it removes the dependencies which are
> marked as NORMAL. When we changed the dependency for partitioned case from
> NORMAL to AUTO by updating StoreCatalogInheritance1(), this function was not
> updated. This caused the dependency to linger behind even after
> detaching the
> partition, thus causing the now standalone table (which was once a
> partition)
> to be dropped when the parent partitioned table is dropped. This patch fixes
> RemoveInheritance() to choose appropriate dependency.
>
> Attached patch 0001 to fix this.
Looks good to me. Perhaps, the example in your email could be added as a
test case.
> I see a similar issue-in-baking in case we change the type of
> dependency recorded between a table and the composite type associated
> with using CREATE TABLE ... OF command. 0002 patch addresses the
> potential issue by using a macro while creating and dropping the
> dependency in corresponding functions. There might be more such
> places, but I haven't searched for those.
Might be a good idea too.
Adding this to the open items list.
Thanks,
Amit