From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | WIP list rewrite |
Date: | 2004-05-23 23:52:59 |
Message-ID: | 40B1395B.3080009@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
partial-list-rewrite-72.patch.gz | application/x-gzip | 62.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-24 00:30:41 | Re: cosmetic psql tweaks |
Previous Message | Neil Conway | 2004-05-23 22:20:56 | cosmetic psql tweaks |