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
