WIP list rewrite
От | Neil Conway |
---|---|
Тема | WIP list rewrite |
Дата | |
Msg-id | 40B1395B.3080009@samurai.com обсуждение исходный текст |
Ответы |
Re: WIP list rewrite
|
Список | pgsql-patches |
I've attached the latest list rewrite patch (gzip'ed, against current sources). Unfortunately, the compatibility API we defined earlier wasn't that effective: it was more efficient for me to look at more or less every lfirst() call site in the backend and rewrite it as necessary than to just start up the backend and wait for things to break. I've done that now, so I think the patch is fairly close to being ready for application. Known problems/TODOs: - rewrite some macros to be GCC inline functions to avoid double-evaluation, per discussion off list with Tom - reorganize list.c to get rid of list_append_auto() and so on, per discussion off list with Tom - adapt a few tricky spots in the code to the new list API (e.g. catalog/dependency.c circa line 994, optimizer/prep/prepunion.c circa line 662) - change over more code to use the new forboth() macro (this can wait until the initial work is applied) - add a new macro/function that gives the value of the head node, given a List. Right now, there are lots of places that do: lfirst(list_head(some_list)) which ought to be a single macro for code clarity (we'd need _int and _oid variants, as well). Any suggestions for what to name this? I'm thinking linitial(), but I'm open to alternatives - fix the remaining bugs this patch has introduced. At the moment, I'm trying to track down the following bug: SELECT n.nspname as "Schema", c.relname as "Name", CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' END as "Type", u.usename as "Owner" FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_user u ON u.usesysid = c.relowner LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN ('r','v','S','') AND n.nspname NOT IN ('pg_catalog', 'pg_toast') AND pg_catalog.pg_table_is_visible(c.oid) ORDER BY 1,2; ==> ERROR: table reference "c" is ambiguous It seems we're mangling pstate->p_namespace in parse_relation.c somehow, but I haven't managed to figure out why yet (any suggestions welcome) I'm working hard to get this finished by the end of this week. -Neil
Вложения
В списке pgsql-patches по дате отправления: