Tom Lane wrote:
elein <elein@varlena.com> writes:
This is what I did:
CREATE TABLE foo(a int, b int);
CREATE TABLE bar(myfoo foo, c int);
This does not actually work, never has worked (at least not as you're
expecting), and is unlikely to start working in the near future.
The only reason it's not rejected out of hand is that there are still
traces in the code of an old Postquel feature that had this as its API.
It did not work anywhere near the way you think, though. As best I
understood it, what would actually be stored in a row of table bar would
be the OID of a function declared as "function() returns setof foo", and
there was some syntax or other for calling this function and getting
back the potentially-many rows it would return. I believe that in the
Postquel system there was actually syntactic sugar for creating nameless
functions of this kind given a Postquel query string that would return
the correct rowtype; so you could imagine the contents of such a field
as being a query that would be executed on-demand and return a table.
Possibly different tables each time you tried it, too.
None of the syntactic sugar is there anymore, and I doubt that the
underlying ability to call a function whose OID appears in a field
works anymore either, even though (some of?) the code for it is still
around. No one's gotten round to ripping it out entirely, but we
probably should, if it's possible to cause core dumps by creating tables
with complex types as columns. For sure I have no interest in trying to
resurrect the Postquel behavior.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
From an object oriented standpoint the ability to store pointers to function at the table level would be outstanding. Not that I have the time or the fortitude to submit a patch for it, just saying think of the possibilities.