Subject: complex data types ..

From: [email-masked] (Bruce Taneja.)
Date: Thu, 26 May 1994 00:28:45 -0400 (EDT)

Is there a way to call the user-defined-data-type functions 
in the data types that use those simpler data types .. ;=) example follows:

******************
	/* from pyramid.c  

A pyramid is constructed out of a base circle and a point at certain
height above the center of the circle */
******************

typedef struct{
	CIRCLE 	c;
	double height;
	} PYRAMID;

******************
/* intended input format:
		create table-x (pyramid1 = pyramid) \g

		append to table-x (pyramid1 = "(2, (3.0, 1.1, 2.1))" )

	please doing worry about syntax errors ;), following is the crux: */
******************

PYRAMID pyramid_in (str)
char * str
{
   pyramid * result ;

	/* BLAH - BLAH parser  */

result->height = atof (etc "2");

******************
/*  *** now how in the world do I call the circle_in function (parser) here
and let it parse the rest of the "(3.0, 1.1, 2.1)" from above append .. 

 One simple way would be to go result->c.center.x= .. , result->c.radius=... etc

but I do NOT want to do this .. !! .. knowing some way of calling parsers
from sub-data-types will help tremendously parsing data at higher level of
nestings .. */
******************

Q.2 does some body know at how many nested levels of complex data types
does postgres becomes unstable ... ?????

Q.3 Can we use nested structs within a single new-data.c file  (like circle.c)

******************
thanks a lot folks for listening in, hope u know more that I do !
Bruce!

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "[email-masked]"

   If this fails, send mail to "[email-masked]" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================

---

From: [email-masked] (Paul M. Aoki)
Date: Wed, 25 May 94 22:07:50 -0700

> and let it parse the rest of the "(3.0, 1.1, 2.1)" from above append .. 

you could call circle_in.  the existing adt code is in src/utils/adt.

circle_in will return a piece of palloc'd memory (as should your 
input function).  using a standard input function as a parser 
means that at some point you would have to copy the returned 
structure into your final structure (the one returned by 
pyramid_in) so that it's all contiguous.  you would have to pfree
the thing returned by circle_in, too.

if you have more complex, variable-length data types, you could
do something like assemble a recursive pointer-based structure 
and then flatten it out at the end.  that's if you really, really
want to use input functions.  if you use slightly-hacked variants
that write into caller-provided buffers (code that you could 
actually re-use in the input functions) you could do something 
cleaner.

> Q.3 Can we use nested structs within a single new-data.c file  (like circle.c

all postgres wants to know is that an adt is
	- one contiguous hunk of memory (ie contains no pointers)
	- either by-value, by-ref/fixed-length or by-ref/variable-length
	- contained in palloc'd memory

internally, it treats by-ref adts as blobs.  once in internal (core)
format, postgres doesn't do anything funny to it -- the only operations 
it does on it are (1) copy it (eg onto disk pages) and (2) apply 
whatever functions you have written for that adt.

so nesting of c structures shouldn't matter (given the above).  after
all, only the c compiler ever parses your structure definitions.  if
there are problems they probably lie in the input functions themselves
(not calling palloc, pfree'ing the wrong thing, returning the wrong
thing, etc.).
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki