fdw_private and (List*) handling in FDW API
От | Tomas Vondra |
---|---|
Тема | fdw_private and (List*) handling in FDW API |
Дата | |
Msg-id | 9055df78ae2d481d05ee805dfc63c3d5.squirrel@sq.gransy.com обсуждение исходный текст |
Ответы |
Re: fdw_private and (List*) handling in FDW API
|
Список | pgsql-hackers |
Hi, I've been exploring the new FDW API in the past few days, and I'm slightly confused by the fdw_private fields. A few comments: 1) Generally all the API functions pass data using fields in the nodes (e.g. GetForeignRelSize uses baserel->fdw_private etc.), but PlanForeignModify simply returns the data, and BeginForeignModify accepts that as a regular parameter. Is there any particular reason not to adapt the same approach in all cases, i.e. either return the private data in all cases (and pass as parameters), or passing them inside node/plan/...? 2) Is there any particular reason why PlanForeignModify/BeginForeignModify require the fdw_private to be a List*, and not a generic pointer? I mean, RelOptInfo declares fdw_private as a (void*) but the other structures (e.g. ForeignScan) switches to (List*) for some reason. But all the optimizer does with this data is this in createplan.c fdw_private_list = NIL; i = 0; foreach(lc, resultRelations) { ... fdw_private = fdwroutine->PlanForeignModify(root,node, rti, i); fdw_private_list = lappend(fdw_private_list, fdw_private); i++; } node->fdwPrivLists = fdw_private_list; return node; If I read that correctly, it just accumulates all the lists into a single list (and then unpacks that into individual lists in nodeModifyTable.c). What is the reason for using (List*) here? I'd rather use a structure here, not generic lists, YMMV. Or is there something I missed (e.g. future plans)? regards Tomas
В списке pgsql-hackers по дате отправления: