Re: Trouble with bytea in SPI...

From: "Cristian Prieto" <cristian(at)clickdiario(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Trouble with bytea in SPI...
Date: 2005-09-02 18:17:09
Message-ID: 02ff01c5afea$8b6d6ea0$6500a8c0@gt.ClickDiario.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

First at all, thanks a lot for your help with my trouble, it was very
helpfull...

This is my complete code:

#include "postgres.h"
#include "fmgr.h"
#include "executor/spi.h"

#include <gsl/gsl_rng.h>

PG_FUNCTION_INFO_V1(myspi);

Datum
myspi(PG_FUNCTION_ARGS)
{
int ret;
bool isnull;

bytea *val;
void *plan;
Oid *karg;
Datum newval[1];

// -- La parte de numeros aleatorios va aki
gsl_rng_type *T;
gsl_rng *r;

void *stat;
int res;
int num;

num = PG_GETARG_INT(0);
if(PG_ARGISNULL(0)) {
PG_RETURN_NULL();
}

gsl_rng_env_setup();
T = gsl_rng_default;
r = gsl_rng_alloc(T);

ret = SPI_connect();
karg = (Oid *) palloc(sizeof(Oid));

ret = SPI_exec("SELECT st FROM rng_seeds", 1);
if (ret == SPI_OK_SELECT && SPI_processed > 0) {
TupleDesc tupdesc = SPI_tuptable->tupdesc;
SPITupleTable *tuptable = SPI_tuptable;

val = DatumGetByteaP(SPI_getbinval(tuptable->vals[0], tupdesc, 1,
&isnull));
karg[0] = SPI_gettypeid(tupdesc, 1);
}

stat = r->state;
memcpy(stat, VARDATA(val), gsl_rng_size(r));
res = (int) gsl_rng_uniform_int(r, num);

/* Aki retorno el valor modificado a su respectiva celda */
memcpy(VARDATA(val), stat, gsl_rng_size(r));
plan = SPI_prepare("UPDATE rng_seeds SET st=$1", 1, karg);
if (!plan)
elog(ERROR, "I don't know what happened!");
plan = SPI_saveplan(plan);

newval[0] = PointerGetDatum(val);
ret = SPI_execp(plan, newval, NULL, 0);

SPI_finish();
gsl_rng_free(r);

PG_RETURN_INT32(res);
}

And thanks to all of you it works as expected, the theory behind this is the
following:
gsl random library has a lot different kind of random number generators and
support for some random distributions, so I decide to implement it for a
project I've been working on. I can store the "state" of a random number to
use it to generate the next one. The state is a segment of the memory and it
is stored in a bytea field, so I decided to create a table and in the future
add a name field and handle it as a sequence (ala nextrandval('name'))...

Right now it works just with one field and I guess it is working well, but I
am very worried about the performance of SPI_execute() and SPI_execp(). I
read in the Developer FAQ something about accessing the data directly from
the backend code. If it is like this I would like to get more infor about
how to use SearchSysCache() and heap_beginscan().

Do you think I need to implement such thing to improve performance? any idea
in how to improve my approach to this trouble?

Thanks a lot for your answer!

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Michael Fuhr" <mike(at)fuhr(dot)org>
Cc: "Cristian Prieto" <cristian(at)clickdiario(dot)com>;
<pgsql-general(at)postgresql(dot)org>
Sent: Thursday, September 01, 2005 9:51 PM
Subject: Re: [GENERAL] Trouble with bytea in SPI...

> Michael Fuhr <mike(at)fuhr(dot)org> writes:
>> On Thu, Sep 01, 2005 at 08:23:31PM -0600, Cristian Prieto wrote:
>>> Hello, I've been working just a little with SPI in a few stored
>>> functions, this is a model of my SP:
>
>> Please post a real example instead of a "model."
>
> Also, it's good to make at least some minimal effort with gdb to find
> out where your code is crashing. A backtrace from the core dump
> (or from catching the signal interactively) often tells a lot.
>
> regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sergey E. Koposov 2005-09-02 18:23:55 operators, operator classes, Btree and index usage
Previous Message Matt Miller 2005-09-02 17:33:17 Re: Self creating tables