Thread: Major problem with custom data type
Hi,
I posted a message yesterday about creating a custom datatype where I store an array of custom strucs. Well I finished
implementingit today, but I can not get it to work within postgres. I have compiled the C code in a seperate test
file(rippingout all the postgres related function calls), and gotten it to store my custom data type perfectly and then
spitit back out as a string. My problem is when I try to use it in postgres, the input argument to my output
function(thepointer to the data) seems to be corrupted somehow.
In my input function I have this(after parsing the input string and setting up the data):
/*
The AtomLocation is the type of the struc to be stored in the array
temp_index is the number of structs to be stored and I add 4 for the word at the beginning that tells postgres the
length.
point_strucs is a pointer to the beginning of the actual strucs.
temp_points is a local array that is temporarily holding the data that is internal to the strucs./*
result = (void *) palloc((sizeof(AtomLocation) * temp_index) + 4);
*((int *) result) = (sizeof(AtomLocation) * temp_index) + 4;
point_strucs = (AtomLocation *) (((char *) result) + 4);
for(i = 0; i < temp_index; i++){
point_strucs[i].index = temp_points[i].index;
point_strucs[i].x = temp_points[i].x;
point_strucs[i].y = temp_points[i].y;
point_strucs[i].z = temp_points[i].z;
}
PG_RETURN_POINTER(result);
My output function is obviously not getting passed something correctly. My first two lines are:
int* result = (int *) PG_GETARG_POINTER(0);
int length = *result - 4;
By some simple fprintf statements I can see that when I try to call *result - 4, that it crashes. I used an if
statementand result is not a null pointer. So what could be going on here? I am really stumped... Keep in mind if I
abstractthis to seperate file with no postgres refrences, then IT WORKS PERFECT. So somehow I have passed something
incorrectlyto the PG database.
P.S I tried detoasting the value and all that did was cause it to fail on the first output function line of code. This
customdata type is defined as :
CREATE TYPE atomlocation (
internallength = VARIABLE,
input = atomlocation_in,
output = atomlocation_out
);
"Morgan Kita" <mkita@verseon.com> writes:
> So what could be going on here?
There's nothing obviously wrong in what you posted ... other than the
very poor style of misspelling "VARHDRSZ" as "4", not using VARDATA and
VARATT_SIZEP macros, and generally doing your best to ignore every one
of the portability conventions that are built into the Postgres
sources. This code *will* break at some point in the future, but
it's not immediately obvious why it's not broken on a typical
present-day 32-bit-Intel platform. (Now if that's not what you are
running on, maybe you should mention it...)
When there's nothing broken in what you're looking at, that's usually a
good sign that the problem is elsewhere. Could you post a complete
non-working example rather than just extracts?
regards, tom lane
On Fri, Apr 01, 2005 at 11:21:24PM -0500, Tom Lane wrote:
>
> There's nothing obviously wrong in what you posted ... other than the
> very poor style of misspelling "VARHDRSZ" as "4", not using VARDATA and
> VARATT_SIZEP macros, and generally doing your best to ignore every one
> of the portability conventions that are built into the Postgres
> sources.
Do you recommend always using the macros, even if the data is a
structure? For example, I've done things like the following:
typedef struct foo
{
int32 size;
int32 numitems;
float8 item[1];
} foo;
and then
foo *p;
size = sizeof(*p) + (numitems - 1) * sizeof(p->item);
p = palloc(size);
p->size = size;
p->numitems = numitems;
for (i = 0; i < numitems; ++i)
p->item[i] = /* some value */;
I see similar code in arrayfuncs.c. Is this style safe, or would
you suggest changing the code to use the macros?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
Michael Fuhr <mike@fuhr.org> writes:
> Do you recommend always using the macros, even if the data is a
> structure? For example, I've done things like the following:
> ...
> I see similar code in arrayfuncs.c.
Well, the arrayfuncs.c code falls in the category of "stuff we'll
have to fix when it breaks". That doesn't extend to user-written
C functions; you're on your own if you don't follow best practices.
In any case I'm quite sure that noplace in the arrayfuncs code hardwires
"4" for VARHDRSZ ...
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: >There's nothing obviously wrong in what you posted ... other than the >very poor style of misspelling "VARHDRSZ" as "4", not using VARDATA and >VARATT_SIZEP macros, and generally doing your best to ignore every one >of the portability conventions that are built into the Postgres >sources. This code *will* break at some point in the future, but >it's not immediately obvious why it's not broken on a typical >present-day 32-bit-Intel platform. (Now if that's not what you are >running on, maybe you should mention it...) >When there's nothing broken in what you're looking at, that's usually a >good sign that the problem is elsewhere. Could you post a complete >non-working example rather than just extracts? Hmm I was not aware of those macros, or that I was breaking portability conventions for postgres. If you could direct meas to where I could read up on these things, I would be more than willing to learn about them. I actually figured my own problem out, thank you for pointing out that is was likely not in the code, I found I was missingone of the declaration statements needed by postgres. Once again any links to where I can read up on postgres coding conventions would be great as I have to write a few more ofthese custom data types. I have read through the manual but I am guessing that I missed a section. Thanks, Morgan
"Morgan Kita" <mkita@verseon.com> writes:
> Once again any links to where I can read up on postgres coding conventions would be great as I have to write a few
moreof these custom data types. I have read through the manual but I am guessing that I missed a section.
There's not a lot of "here are the conventions" expository material.
However, there are reams of examples, namely all the built-in datatypes.
The best way to proceed is usually to look for existing code that does
something close to what you want, and adapt it.
regards, tom lane