"Robert B. Easter" <reaster@comptechnews.com> writes:
> Table types were intended to be used like the following example
Not really. What seems to have been implemented back in the PostQUEL
days was "set attributes", by which they meant function attributes:
what was stored in such a field was the OID of a *function*. Retrieval
would run the function, producing one or more tuples from which an
individual field could be selected.
The example you give could have been implemented by defining a function
that executes "select * from t1 where key = something" and then storing
its OID in a row of t2.
This approach had a number of problems, the main one being the confusion
between fields-that-are-function-references and values-that-are-tuples.
There wasn't any distinction made AFAICT, and thus any situation where
a tuple datatype appears as a field of a larger tuple is liable to be
misinterpreted as a function reference instead.
The whole thing strikes me as an academic toy rather than a seriously
usable feature. (Are you really going to want to define a new function
for every row of your table? How should the system know when to get rid
of such functions? Not to mention the horrid memory leaks all over the
place in the implementation.) I'd like to get rid of it and put in a
clean implementation of tuple-valued functions and fields instead.
regards, tom lane