Re: Composite Types - Mailing list pgsql-general

Tom,

Thanks for your feedback and insight. Consider this: Wouldn't it be
fantastically powerful and also type-behavior-consistent if user-defined
composite types (using CREATE TABLE) behave somewhat similar to base types
defined by CREATE TYPE? Again, going back to the earlier example,
the composite type 'bulk':

              Table "bulk"
     Attribute |  Type   | Modifier
    -----------+---------+----------
     id        | integer |
     ofset     | integer |
     size      | integer |

used in:

             Table "stuff"
     Attribute |  Type   | Modifier
    -----------+---------+----------
     id        | integer |
     name      | text    |
     content   | bulk    |

with insertion into 'stuff':

    INSERT into stuff values (1,'test1',(new_bulk(7,8,9)));

and using query:

    SELECT * from stuff where content.id=7;

would result in something like:

     id   |  name  | content.id | content.ofset | content.size
    ------+--------+------------+---------------+-------------
     1    |  test1 | 7          | 8             | 9

Although the above doesn't fit into SQL92, it does fit into OO paradigm to
which Postgres is approaching. The point being that, once the class
'bulk' is created and allowed to be used in another class 'stuff', it seems
logical and appropriate that the attributes of bulk be visible and
accessible to 'stuff'.  Perhaps a Postgres extension to SQL92?

Regards,

Morey Parang
Oak Ridge National Lab
parangm@ornl.gov



On Wed, Jun 07, 2000 at 12:09:45AM -0400, Tom Lane wrote:
> 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