I will submit a patch. As soon as I have read the developers FAQ and learned
how this is done :-)

B.T.W. I needed one additional function. Do you think I should submit it
too? This function copies some behavior found in the SPI_cursor_open. If
submitted, I'd suggest that the SPI_cursor_open calls this method to verify
the plan.

/*
 * Returns true if the plan contains exactly one command
 * and that command originates from normal SELECT (i.e.
 * not a SELECT ... INTO). In essence, the result indicates
 * if the command can be used with SPI_cursor_open or not.
 *
 * Parameters
 *    plan A plan previously prepared using SPI_prepare
 */
bool SPI_is_cursor_plan(void* plan)
{
 List* qtlist;
 _SPI_plan* spiplan = (_SPI_plan*)plan;
 if (spiplan == NULL)
 {
  SPI_result = SPI_ERROR_ARGUMENT;
  return false;
 }

 qtlist = spiplan->qtlist;
 if(length(spiplan->ptlist) == 1 && length(qtlist) == 1)
 {
  Query* queryTree = (Query*)lfirst((List*)lfirst(qtlist));
  if(queryTree->commandType == CMD_SELECT && queryTree->into == NULL)
   return true;
 }
 return false;
}

Regards,
Thomas Hallgren

----- Original Message ----- 
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, February 11, 2004 23:00
Subject: Re: [HACKERS] Request for additional SPI functions.


>
> This seems like a reasonable request.  Care to submit a patch?
>
> --------------------------------------------------------------------------
-
>
> Thomas Hallgren wrote:
> > Short story:
> > I need two new functions in the Server Programming Interface (SPI) when
> > mapping an ExecutionPlan to a Java prepared statement (pljava project).
> >
> > Long story:
> > My problem is that once a plan is prepared and I want to execute it, I
send
> > an array of java objects for the arguments. The
SPI_cursor_open/SPI_execp of
> > course expects the arguments to be Datum's and the mapper must convert
java
> > objects. Knowing the Oid of each type, this is not a problem. Those are
> > hidden in the opaque execution plan (a void*). I'm all in favor of data
> > hiding and reluctant to use spi_priv.h so I propose that you add the
> > following two functions:
> >
> > /*
> > * Returns the number of arguments for the prepared plan.
> > */
> > int SPI_getargcount(void* plan)
> > {
> >     if (plan == NULL)
> >     {
> >         SPI_result = SPI_ERROR_ARGUMENT;
> >         return -1;
> >     }
> >     return ((_SPI_plan*)plan)->nargs;
> > }
> >
> > /*
> > * Returns the Oid representing the type id for argument at argIndex.
First
> > * parameter is at index zero.
> > */
> > Oid SPI_getargtypeid(void* plan, int argIndex)
> >     {
> >     if (plan == NULL || argIndex < 0 || argIndex >=
> > ((_SPI_plan*)plan)->nargs)
> >     {
> >         SPI_result = SPI_ERROR_ARGUMENT;
> >         return InvalidOid;
> >     }
> >     return ((_SPI_plan*)plan)->argtypes[argIndex];
> > }
> >
> > Regards,
> >
> > Thomas Hallgren
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> >                http://archives.postgresql.org
> >
>
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   [EMAIL PROTECTED]               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
19073
>


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to