pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: selkovjr@mcs.anl.gov
To: Lonnie Cumberland <lonnie_cumberland@yahoo.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: composite data types?
Date: Tue, 17 Apr 2001 03:20:26 -0500
Message-ID: <200104170820.DAA02354@selkovjr.xnet.com> (raw)
In-Reply-To: <20010417042748.4019.qmail@web12504.mail.yahoo.com>
References: <20010417042748.4019.qmail@web12504.mail.yahoo.com>

> 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




view thread (3+ messages)  latest in thread

Message-ID: <200104170820.DAA02354@selkovjr.xnet.com>
Permalink:  ../200104170820.DAA02354@selkovjr.xnet.com/
Also on:    postgresql.org/message-id/200104170820.DAA02354@selkovjr.xnet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: selkovjr@mcs.anl.gov, lonnie_cumberland@yahoo.com
  Subject: Re: composite data types?
  In-Reply-To: <200104170820.DAA02354@selkovjr.xnet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox