> > > > > Sounds like the plan internally grew (possible w/subselect stuff?!?) and
> > > > > has gone over that 8k limit.
> > > >
> > > > I think it must be due to the cleanups in the node-print and
> > > > read funcs. They now output/read ALL fields in the nodes.
> > >
> > > Oh, I didn't realize that the print functions were actually used for something
> > > other than printing and debugging. I had started to add a few new nodes when I
> > > was trying to debug the "primary key" code.
> > >
> > > Should we go through and bracket some of those with #ifdef QUERYDEBUG or
> > > something like that? Where are they actually used? Should we try to keep these
> > > at a minimum for production compiles of the system??
> > Did you add stuff to dump that wasn't dumped before, or were they fields
> > of existing structure that used to be skipped?
> > They are used for the rewrite system and for views.
> I added a few nodes (maybe two?), _and_ added some call-outs to existing nodes to
> follow their children down. This stuff can be bracketed with debugging #ifdef's; it
> was very helpful for me when debugging but it isn't good if they are adding
> unnecessary limitations on sizes. The additional nodes I added are a "don't care";
> it's the additional printing of child nodes (fields of existing structures) which
> is loading things down.
> I am not absolutely certain that we are talking about the same thing, so should
> confirm that it is the same routines which are causing trouble; this is the same
> printing/formatting code used for "explain"??
> I'd be happy to help clean them up, but I think you should help too; as I recall we
> were both mucking around there about the same time ;)
I think we talk about the same group of functions. But I'm
not sure if the nodes you're talking about are parsenodes.
Only parsenodes are printed during rule creation to build the
querytree string stored in the pg_rewrite catalog (views are
implemented by rules and do an internal CREATE RULE on CREATE
Anyway - If your nodes are parsenodes and you didn't created
the corresponding node readfuncs, I would expect trouble
during the rewrite handling when the printed rule action is
parsed back to the backends internal querytree structures.
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #
In response to
pgsql-hackers by date
|Next:||From: Edmund Mergl||Date: 1998-03-02 20:17:18|
|Subject: Re: [HACKERS] Perl module installs in wrong place|
|Previous:||From: Bruce Momjian||Date: 1998-03-02 18:42:55|
|Subject: New logo|