Re: [HACKERS] SPI_prepare() doesn't work well ? - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] SPI_prepare() doesn't work well ? |
Date | |
Msg-id | 199901220437.XAA02624@candle.pha.pa.us Whole thread Raw |
In response to | RE: [HACKERS] SPI_prepare() doesn't work well ? ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Responses |
RE: [HACKERS] SPI_prepare() doesn't work well ?
|
List | pgsql-hackers |
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Jan Wieck > Sent: Thursday, January 21, 1999 12:57 AM > To: Hiroshi Inoue > Cc: pgsql-hackers@postgreSQL.org; mcontzen@dohle.com > Subject: Re: [HACKERS] SPI_prepare() doesn't work well ? > > > Hiroshi Inoue wrote: > > > > > Hello all, > > > > It seems that SPI_prepare() doesn't work well in some cases. > > > > Pawel Pierscionek [pawel@astercity.net] reported about the > > following case 1([SQL] drop table in pgsql). > > Michael Contzen [mcontzen@dohle.com] reported about the > > following case 2(PL/PGSQL bug using aggregates). > > > You can find it from pgsql-hackers archive. > > > > > [snip] > > > > > > > 2. Aggregates in PL/pgSQL cause wrong results. > > > > > > Is it proper to use set_agg_tlist_references() function to > > > reconstruct aggs member node for Agg type nodes ? > > > > Don't know. It is important, that the copy of the tree has > > absolutely NO references to anything outside itself. The > > parser/rewrite/planner combo creates all plans in the actual > > transactions memory context. So they will get destroyed at > > transaction end. > > > > In my patch set_agg_tlist_refereces() function is appiled for > copied(new) Agg type nodes,not for original(old) nodes. > > This case is a special case of > > How does copyObject() copy multiply referenced objects ? > > As to this case,PostgreSQL Executor sets aggno's of Aggreg Nodes > using aggs member node of Agg type nodes. > As a result,aggno's of the Aggreg nodes contained in TargetList > are set because they have common pointers. > So multiply referenced Aggreg type nodes must be copied to new > plan as multiply referenced nodes. > It is my understanding that this has always been a problem. I have never 100% been confident I understand it. As I remember, there used to be a: Aggreg **qry_agg that was a member of the Query structure, and cause all sorts of problems because the Agg was in the target list _and_ in the qry_agg. That was removed. Looks like I did it, but I don't remember doing it:revision 1.44date: 1998/01/15 19:00:11; author: momjian; state: Exp; lines: +2 -4Remove Query->qry_aggs and qry_numaggs and replace with Query->hasAggs.Pass List* of Aggregsinto executor, and create needed array there.No longer need to double-processs Aggregs with second copy in Query. The removal of that fixed many problems. Can you explain a little more on how multiple Agg references happen. Perhaps we can get a good clean fix for this. Maybe redesign is needed, as I did for the removal of qry_aggs. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: