WIP list rewrite - Mailing list pgsql-patches

From Neil Conway
Subject WIP list rewrite
Date
Msg-id 40B1395B.3080009@samurai.com
Whole thread Raw
Responses Re: WIP list rewrite  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


Attachment

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: cosmetic psql tweaks
Next
From: Tom Lane
Date:
Subject: Re: cosmetic psql tweaks