Re: CREATE TABLE with a column of type {table name}

I know that this isn't really supposed to work in postgresql.
I was testing a response stephan made to ang chin han's question.

However, the ability to create virtual columns (you brought it
up :-) was quite handy and survived the conversion to SQL
in Illustra (as did row types).  It was not necessarily
the trick Illustra used to implement row/composite types. I'm
not sure what we did in there.

IMNSHO a type is a type is a type.  An instance of anytype
can go in a column.  However, having worked in some of
the code to make this recursive definition work correctly
I understand your "No! Never!"  response.  I don't agree,
with it, but I understand it :-)

elein

On Fri, Aug 01, 2003 at 06:00:41PM -0400, 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
>