Обсуждение: composite data types?

Поиск
Список
Период
Сортировка

composite data types?

От
Lonnie Cumberland
Дата:
Hello All,

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.

So where can I get some information on creating coposite data types? And how
can I use one of these in my "C" extension functions.

Also, could someone please explain to me what this return type of "opaque" is?

Cheers and Thanks to all for the help that you have provided me,
Lonnie

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


Re: composite data types?

От
selkovjr@mcs.anl.gov
Дата:
> 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



Re: composite data types?

От
Lonnie Cumberland
Дата:
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/