Re: CREATE TABLE with a column of type {table name}
От | elein |
---|---|
Тема | Re: CREATE TABLE with a column of type {table name} |
Дата | |
Msg-id | 20030801154235.A22103@cookie обсуждение исходный текст |
Ответ на | Re: CREATE TABLE with a column of type {table name} (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CREATE TABLE with a column of type {table name}
|
Список | pgsql-general |
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 >
В списке pgsql-general по дате отправления: