Re: composite data types? - Mailing list pgsql-interfaces
From | Lonnie Cumberland |
---|---|
Subject | Re: composite data types? |
Date | |
Msg-id | 20010418190610.47976.qmail@web12504.mail.yahoo.com Whole thread Raw |
In response to | Re: composite data types? (selkovjr@mcs.anl.gov) |
List | pgsql-interfaces |
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@mcs.anl.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/
pgsql-interfaces by date: