ERROR: cache lookup failed for type 0

[Tom Lane]

Tzahi Fadida <tzahi_ml@myrealbox.com> writes:

> It still doesn't work. btw, I am using 8rc2.

Um. The "clean" way to do this is to use BlessTupleDesc and then
heap_formtuple. That requires you to break down the original tuple
into fields (see heap_deformtuple). Alternatively you could poke
the datatype ID fields directly into the copied tuple.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Tzahi Fadida]

well, I tried the heap_deformtuple and I am getting now:
select testgetrows();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

btw, as can be seen below I tried two kinds of tupledesc just in case
with the same results.
/*funcctx->tuple_desc= BlessTupleDesc(fctx->lRel->rd_att);*/
funcctx->tuple_desc=BlessTupleDesc(RelationNameGetTupleDes c("my_first_ta
ble"));

#include "postgres.h"
#include <string.h>
#include <array.h>
#include "fmgr.h"
#include "funcapi.h"
#include "access/heapam.h"

typedef struct
{
HeapScanDesc scan;
Relation lRel;
} testgetrows_fctx;

PG_FUNCTION_INFO_V1(testgetrows);

Datum
testgetrows(PG_FUNCTION_ARGS)
{
FuncCallContext *funcctx;
testgetrows_fctx *fctx;
if (SRF_IS_FIRSTCALL())
{
MemoryContext oldcontext;
funcctx = SRF_FIRSTCALL_INIT();

oldcontext =
MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
fctx = (testgetrows_fctx *) palloc(sizeof(testgetrows_fctx));
fctx->lRel = heap_open(17236, AccessShareLock);
fctx->scan = heap_beginscan(fctx->lRel, SnapshotNow, 0, NULL);

/*funcctx->tuple_desc= BlessTupleDesc(fctx->lRel->rd_att);*/

funcctx->tuple_desc=BlessTupleDesc(RelationNameGetTupleDes c("my_first_ta
ble"));

funcctx->user_fctx = fctx;
MemoryContextSwitchTo(oldcontext);
}

funcctx = SRF_PERCALL_SETUP();
fctx = funcctx->user_fctx;

HeapTuple tuple;
tuple = heap_getnext(fctx->scan, ForwardScanDirection);
if (HeapTupleIsValid(tuple))
{

Datum result;
Datum *values;
HeapTuple tupleCopy;
HeapTuple tupleCopy2;
char *nulls = (char *)palloc(funcctx->tuple_desc->natts *
sizeof(char));

tupleCopy = heap_copytuple(tuple);
heap_deformtuple(tuple,funcctx->tuple_desc,values,nulls);
tupleCopy2 = heap_formtuple(funcctx->tuple_desc,values,nulls);
result = HeapTupleGetDatum(tupleCopy2);

SRF_RETURN_NEXT(funcctx, result);

}
else /* do when there is no more left */
{
heap_endscan(fctx->scan);
heap_close(fctx->lRel, AccessShareLock);

SRF_RETURN_DONE(funcctx);
}
}
Regards,
tzahi.

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, January 07, 2005 10:31 PM
> To: Tzahi Fadida
> Cc: [email]pgsql-general@postgresql.org[/email]
> Subject: Re: [GENERAL] ERROR: cache lookup failed for type 0
>
>
> Tzahi Fadida <tzahi_ml@myrealbox.com> writes:

> > It still doesn't work. btw, I am using 8rc2.

>
> Um. The "clean" way to do this is to use BlessTupleDesc and
> then heap_formtuple. That requires you to break down the
> original tuple into fields (see heap_deformtuple).
> Alternatively you could poke the datatype ID fields directly
> into the copied tuple.
>
> regards, tom lane
>
>

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [email]majordomo@postgresql.org[/email] so that your
message can get through to the mailing list cleanly

[Tom Lane]

Tzahi Fadida <tzahi_ml@myrealbox.com> writes:

> well, I tried the heap_deformtuple and I am getting now:
> select testgetrows();
> server closed the connection unexpectedly

You didn't palloc the values array. Any reasonable compiler would have
warned you about that BTW. If you don't have compiler warnings enabled,
learn to use them.

Also, I'd recommend using the tupledesc from the just-opened lRel;
fetching it via an independent path is just asking for trouble.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Greg Stark]

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Tzahi Fadida <tzahi_ml@myrealbox.com> writes:

> > well, I tried the heap_deformtuple and I am getting now:
> > select testgetrows();
> > server closed the connection unexpectedly

>
> You didn't palloc the values array. Any reasonable compiler would have
> warned you about that BTW. If you don't have compiler warnings enabled,
> learn to use them.

I think with gcc this type of warning is only enabled when you're compiling
with optimizations. Most people don't compile with optimizations enabled when
developing.

--
greg


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [email]majordomo@postgresql.org[/email]

[Tom Lane]

Greg Stark <gsstark@mit.edu> writes:

> Tom Lane <tgl@sss.pgh.pa.us> writes:

>> You didn't palloc the values array. Any reasonable compiler would have
>> warned you about that BTW. If you don't have compiler warnings enabled,
>> learn to use them.

> I think with gcc this type of warning is only enabled when you're compiling
> with optimizations. Most people don't compile with optimizations enabled when
> developing.

Pretty much the first thing you learn when developing with gcc is to use
-O1 -Wall for compiling devel code. Gets all the warnings and doesn't
confuse gdb too badly. Once in a long while I'll recompile an
individual file with -O0 so that I can single-step through it more
easily, but 99.44% of the time I'd rather have the
uninitialized-variable warning.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [email]majordomo@postgresql.org[/email]