Обсуждение: Request for additional SPI functions.
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
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,
Pennsylvania19073
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;}returnfalse;
}
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, Pennsylvania19073