Is this a bug?

From: "Roberto Abalde" <roberto(dot)abalde(at)galego21(dot)org>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Is this a bug?
Date: 2001-06-08 20:19:43
Message-ID: 000901c0f058$76ab4ce0$e1023dc8@ultra
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi people,

I've found that some two functions in /src/backend/optimizer/plan/planner.c
have side effects.

First, I've added two pprints before and after line 89-90 like this.

pprint(parse->rtable);

/* primary planning entry point (may recurse for subqueries) */
result_plan = subquery_planner(parse, -1.0 /* default case */);

pprint(parse->rtable);

Then I ran the query "select * from F1 where fk6 > 50;" and get this on the
log (I put "<<<<<<" to highlite the differences)

DEBUG: query: select * from F1 where fk6 > 50;
(
{ RTE
:relname f1
:relid 782787
:subquery <>
:alias <>
:eref
{ ATTR
:relname f1
:attrs ( "pk" "fk1" "fk2" "fk3" "fk4" "fk5" "fk6" "valu
e" )
}

:inh true <<<<<<
:inFromCl true
:checkForRead true
:checkForWrite false
:checkAsUser 0
}
)
(
{ RTE
:relname f1
:relid 782787
:subquery <>
:alias <>
:eref
{ ATTR
:relname f1
:attrs ( "pk" "fk1" "fk2" "fk3" "fk4" "fk5" "fk6" "valu
e" )
}

:inh false <<<<<<
:inFromCl true
:checkForRead true
:checkForWrite false
:checkAsUser 0
}
)

So, parse->rtable->inh changes. In the same way I've tested
"set_plan_references" (lines 97-98)

pprint(parse->jointree);

/* final cleanup of the plan */
set_plan_references(result_plan);

pprint(parse->jointree);

Again I ran the query "select * from F1 where fk6 > 50;" and get this on the
log (I put "<<<<<<" to highlite the differences)

DEBUG: query: select * from F1 where fk6 > 50;
{ FROMEXPR
:fromlist (
{ RANGETBLREF 1
}
)

:quals (
{ EXPR
:typeOid 16
:opType op
:oper
{ OPER
:opno 521
:opid 0 <<<<<<<<<<<<<
:opresulttype 16
}
...

{ FROMEXPR
:fromlist (
{ RANGETBLREF 1
}
)

:quals (
{ EXPR
:typeOid 16
:opType op
:oper
{ OPER
:opno 521
:opid 147 <<<<<<<<<<<<<
:opresulttype 16
}

Now, parse->jointre->opid changes. The odd thing is that
"set_plan_references" does not have "parse" as a parameter (!).

I need help to check this again to see if these are actual bugs. Can someone
help me with this? BTW, I'm using the 7.1.1 sources.

Saludos,
Roberto

---------------------
A "No" uttered from deepest conviction is better and greater than a "Yes"
merely uttered to please, or what is worse, to avoid trouble. -- Mahatma
Gandhi

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Ivar Helbekkmo 2001-06-08 21:06:52 Re: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
Previous Message Tom Lane 2001-06-08 19:37:34 Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)