From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: refactoring planner data structures |
Date: | 2005-06-06 02:32:17 |
Message-ID: | 5959.1118025137@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> I was rather disappointed, as I wasn't able to find a clean
> way to get around the problem described in the thread above -- e.g.
> in_info_list and query tree mutators:
> http://archives.postgresql.org/pgsql-hackers/2005-03/msg00718.php
> How were you thinking of solving it?
Yeah, that gave me some headaches :-(. It turns out that most of the
uses of walkers/mutators are on not-yet-planned Querys and so the
failure to visit the in_info_list doesn't matter. I had to add code in
just two places to visit the in_info_list explicitly.
Plan B would be to add PlannerInfo as a node type that the
walker/mutator code knows how to traverse. I didn't do this for the
moment because it's not immediately obvious why the traverse should only
visit the Query and the in_info_list subfields; that seems sufficiently
ad-hoc to be better kept at the call sites for the moment. Maybe we can
revisit that later.
Ideally I'd like to get rid of in_info_list altogether ... it's a bit of
a kluge. Don't see how to do that yet though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-06-06 02:32:49 | Re: Do we force dependency? |
Previous Message | Neil Conway | 2005-06-06 02:18:22 | Re: lastval() |