I'm intending to remove the "planner internal" fields of Query
(base_rel_list et al) and put them into a separate struct along
the lines of

typedef struct PlannerInfo
{
NodeTag type;

Query *parse; /* the Query being planned */

List *base_rel_list; /* list of base-relation RelOptInfos */
List *other_rel_list; /* list of other 1-relation RelOptInfos */
List *join_rel_list; /* list of join-relation RelOptInfos */
... etc ...
} PlannerInfo;

The planner's routines will all now pass one of these around instead
of a bare Query. PlannerInfo will never go to disk, since it only
lives as long as the planning stage runs, and so this isn't an initdb
forcing change. (We weren't writing the planner fields of Query to
disk anyway, which was ugly but necessary.)

I have several reasons for doing this: it's logically cleaner; it's
an essential first step towards someday making the planner not scribble
on its input; and I'm thinking of replacing join_rel_list with a
hashtable and would prefer not to expose that in something so widely
known as Query.

Any comments, objections? This shouldn't affect any code outside the
planner, so AFAIK it won't break any patches-in-progress.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Neil Conway <neilc@samurai.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...3/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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq