Hi,

> The index creation happens after the new table (which is LIKE the parent)
> has been created, by appending the cxt.alist information to
> "extras_after". The entry point for the index creation is thus via
> ProcessUtility which expects an IndexStmt structure. That is why the current
> patch does all the Oid to name mapping exercise to populate the relevant
> fields in IndexStmt some of which are char pointers. The internal
> DefineIndex function also expects most of the fields to be in IndexStmt like
> format.
>
> If we want to follow the above suggestion, as I understand it, we might
> have to devise a new structure to contain Oids and make ProcessUtility
> accept a new nodeTag. We will also not be able to use existing Index
> definition functions and this will lead to more coding IMHO. Do we want to
> go down this path? Or is there something else that has been suggested above
> and that I am missing completely?


OTOH, we can populate a new structure with the relevant Oids, IndexInfo
information from parent relation indexes and call index_create directly
from within ProcessUtility. Guess, it should be cleaner than the current
approach.

Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com