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 ?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
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:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] SPI_prepare() doesn't work well ?
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] GROUP BY / ORDER BY string is very slow