Subject: c-functions

From: Lydia Wuerfl <[email-masked]>
Date: Fri, 16 Jul 93 03:50:49 -0700

Hello again, 
 PLEASE help me! 

I have written a C - program for arrays.

That is the problem:

* define type textarray
(input = array_in, output = array_out, 
internallength = variable, element = text)\g

* create tg (id = int4, a = textarray)\g
* retrieve (tf.all)\g
-----------------------------
| id          | a           |
-----------------------------
| 1           | {"fritz","franz","hans"}|
-----------------------------
| 2           | {"fritz","karl"}|
-----------------------------
| 3           | {"karli","hans"}|
-----------------------------
| 4           | {"Felix","Thomas","Martin"}|
-----------------------------

* define function cont_textarr
(language = "c", returntype = bool)
arg is (textarray, text)
as "/home/dino/wuerfl/textarr.o"\g

* retrieve (tf.all)       
where cont_textarr(tf.a, "fritz")\g

This function should select all instances where an array element
is "fritz", in this case

-----------------------------
| id          | a           |
-----------------------------
| 1           | {"fritz","franz","hans"}|
-----------------------------
| 2           | {"fritz","karl"}|

this sould be the correct result, but I received 
the following message:

NOTICE:Jul 14 14:00:50:type mismatch in invocation of function cont_textarr
WARN:Jul 14 14:00:50:no such attribute or function cont_textarr

* define operator @
(arg1 = textarray, arg2 = text, 
procedure = cont_textarr)\g

* retrieve (tf.all) where tf.a@"fritz"\g
WARN:Jul 14 14:39:30:OperatorDef: no operator @

* retrieve (tf.all) where tf.a@fritz\g
WARN:Jul 14 14:40:03:type id lookup of 357 failed

also the operator did not work.

I always got this error message when I used text or char16 in 
my function definition.
I also wrote a function for the same problem for the typ int4
example:
 
create f (id = int4, a = intarray)\g
retrieve (t.all) where contains_intarray(t.a, 4)\g
retrieve (t.all) where f.a@4\g

all these things worked correctly

But what about STRINGS ????

My C function:
If I define char aKey I get the message type mismatch ...

int
cont_textarr (char **anArray, char aKey)
{
        int i;
        int ac;
        int ret = 0;
        char *str;
        char *array_out();
        str= array_out(anArray, 25);

             ac =  array_count (str,',');

             for (i=1; i <= ac; i++)
             {
               ret = (strcmp (anArray[i],aKey)==0);
               if (ret != 0) break; 
             }

             pfree (str);
             return ret;

}

PLEASE send me soon an answer. I want to finish my work within the next week.
If it is not possible to write such a function, please send me this information.

THANKS

Lydia

---

From: [email-masked] (Paul M. Aoki)
Date: Fri, 16 Jul 93 08:14:45 -0700

> where cont_textarr(tf.a, "fritz")\g

try
	cont_textarr(tf.a, "fritz"::text)

> * retrieve (tf.all) where tf.a@fritz\g

try
	tf.a @ "fritz"::text

avi pfeffer finally fixed the default type-casting code for text/char16.
this fix will be in 4.2.  meanwhile, make sure you explicitly typecast
all instances of text and char16 in your queries.

>                ret = (strcmp (anArray[i],aKey)==0);

this code is wrong.  in 4.1, both arguments should be (struct varlena *)
(see src/tmp/postgres.h).  (the implementation of arrays will change in 
4.2.)  you can also see src/doc/manual.me for a VERY brief description 
of what variable-length structures look like in postgres.

if you want to understand how to walk an array of variable-length
types, you'll have to read src/utils/adt/arrayfuncs.c.  the short
answer is: textarray is a struct varlena containing a bunch of
other struct varlenas (since text is also implemented as struct varlena).
text is *NOT* implemented as a \0-terminated string, so use of strcmp 
on text will eventually cause segmentation violations.  you can use the
function "texteq" that is built into postgres.

this interface is not well-documented, to say the least.  however, given 
that the array implementation was an awful hack (prior to 4.2), i don't 
think anybody really wanted to document it and admit how it was done :-)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki