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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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" <pgman@candle.pha.pa.us>
To: "Thomas Hallgren" <thhal@mailblocks.com>
Cc: <pgsql-hackers@postgresql.org>
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
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania

19073

Thomas Hallgren wrote:

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.

Sure, add that one too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073