Re: Composite Types
От | Tom Lane |
---|---|
Тема | Re: Composite Types |
Дата | |
Msg-id | 1948.960350985@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Composite Types (mjp@ornl.gov) |
Ответы |
Re: Composite Types
Re: Composite Types |
Список | pgsql-general |
mjp@ornl.gov writes: > I appreciate any help I can get on this...Recently, I've been experimenting > with the user defined base-types (using CREATE TYPE) with successful results. > But, when it comes to handling classes as composite types, things are not > as straight forward. The function-returning-composite-type feature is something we inherited from Berkeley Postgres ---- it doesn't fit into SQL92 at all, and I don't think any of the current crop of developers even understand it very well. It's certainly suffering from bit-rot. The "hobbies" examples in the regression tests seem to be meant to illustrate how it was supposed to work, but I don't find them either intelligible or persuasive. > If I type: > select content from stuff; > I get: > content > ----------- > 136585664 > (1 row) I believe you are looking at a numeric equivalent of a pointer-to- TupleTableSlot there. Somewhere in the mists of Berkelian prehistory, there must have been some code that did something useful with that kind of function result, but I sure as heck can't find much trace of it now. I have been thinking lately that functions returning tuples might fit into SQL92 better as table sources. That is, instead of select foo(bar).whatdoyouwritehere ... we could write something like select elementa,elementc+1 from foo(bar) That doesn't work at the moment, of course, but it's something we could think about causing to work as part of the querytree redesign planned for 7.2. Thoughts anyone? regards, tom lane
В списке pgsql-general по дате отправления: