Tom Lane wrote:
> > I thought that the original berkeley doco covered this to some extent.
>
> Where would I find that?
No offence intended guys, but I'm a bit shocked that you're all hacking
on
postgres without having read the design docs. The design docs are
extremely cool and I'd personally like to see the database return
to the glory days of all this cool technology, features and ideas.
(Hey wouldn't even mind if it went back to postquel hey hey :)
Ok, the postgres 4.2 distribution is at
http://s2k-ftp.cs.berkeley.edu:8000:8000/postgres/postgres-v4r2/
and it has the design docs inside it.
Here is a little excert from one doc...
In addition to the Retrieve-portal command, portals can be defined by an
Execute
command.
For example, suppose the EMP relation had a field of type POSTQUEL
named ``hobbies''
EMP (name, salary, age, hobbies)
that contained commands to retrieve a person's hobbies from the
following
relations:
SOFTBALL (name, position, batting-avg)
COMPUTERS (name, isowner, brand, interest)
An application program can define a portal that will range over the
tuples
describing a person's hobbies as follows:
execute portal H(EMP.hobbies)
where EMP.name = ``Smith''
This command defines a portal, named ``H,'' that is bound to Smith's
hobby records.
Since a person can have several hobbies, represented by more than on
Retrieve
command in the ``hobbies'' field, the records in the
buffer may have different types.
Consequently,
HITCHING POST must provide routines that allow the program
to determine the number of fields, and the type, name,
and value of each field in each record fetched into the buffer.