Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199405260507.WAA07004@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199405260507.WAA10327@faerie.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: aataneja@cs.mtu.edu (Bruce Taneja.)
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: complex data types .. 
Reply-To: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
In-reply-to: Your message of Thu, 26 May 1994 00:28:45 -0400 (EDT) 
	     <9405260428.AA02346@cs.mtu.edu> 
Date: Wed, 25 May 94 22:07:50 -0700
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Wed, 25 May 94 22:07:56 -0700
Resent-XMts: smtp

aataneja@cs.mtu.edu (Bruce Taneja.) writes:
> /*  *** 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 .. 

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.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

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  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================