> 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
