Re: composite data types?

Hello All,

I read over the documentation on creating and using composite data types, but
the examples only illistrated how to call a function with a composite data type
and not how to return one which is what I need to do.

I am thinking that I can make a composite data type link

Keys {

text privatekey;
text publickey;
}

or something similar and then define a structure in my "C" extensions that is
also similar so that I can work with it and then return it back to the psql
command interpreter.

Anone one have any ideas on how I can do this?

The basic problem is that I need to return 2 values from one of my "C"
functions back to the command interpeter.

I am now also working in version 7.1 which I just have now installed.

Cheers,
Lonnie
--- selkovjr(at)mcs(dot)anl(dot)gov wrote:
> > I had an idea recently about a possible way to solve one of my problems for
> > communicating with my "C" extentsion functions.
> >
> > What I might be able to do is to create a composite data type composed of
> two
> > text fields that my "C" function could use as well and return this type to
> the
> > psql command interperter.
>
> One should be able to do that. I haven't tried that myself, but so
> i've been told:
>
> http://www.postgresql.org/users-lounge/docs/7.1/programmer/xfunc-c.html
>
> (see 13.4.4 within)
>
> > Also, could someone please explain to me what this return type of "opaque"
> is?
>
> You can think of it as a pointer. Sort of like float *, except you
> can't obtain the value by simply de-referencing it. Instead, you pass
> the pointer as an argument to a function that gets the value from the
> structure to which it points.
>
> Originally, the word was meant to emphasize the complete encapsulation
> of the type: nothing is known about the type internals from the server
> standpoint. All that is known is the location of chunks of memory
> representing instances of such type and what procedures can be used on
> them. By contrast, the structure of composite types can be seen from
> the server code,
>
> The following document has an explanation of opaque types (and it is a
> nice overview of the ORDB technology)
>
> http://www-scf.usc.edu/~csci586/cs586_reading_12.pdf
>
> The following article seems to equate the meanings of 'opaque', ADTs,
> and 'base types':
>
> http://www.postgresql.org/devel-corner/docs/postgres/type-system.html
>
> However, inside a C function, 'opaque' may also mean 'unknown'.
> Tom Lane says (in
> http://www.postgresql.org/mhonarc/pgsql-general/2000-11/msg00804.html)
>
> > No, it isn't a type at all. Opaque really means, in essence, that
> > you're not saying what the function's arguments or result are.
>
> > There are several reasons for handling datatype I/O routines that way:
>
> > 1. The actual argument types include C strings, which aren't an SQL
> > datatype.
>
> > 2. The I/O routines for a new type have to be defined before you can
> > say CREATE TYPE, and thus they can't name their true input or result
> > type anyway.
>
> > 3. We have some "generic" I/O routines like array_in and array_out,
> > which work for multiple datatypes and so can't be declared as taking
> > any specific datatype.
>
> --Gene
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/