Re: Bug and/or feature? Complex data types in tables...

Understanding in complete detail why it is hard to
have tuples as column values, I still see the need
and uses for composite datatypes.

As Chris said, it allows people to use objects at
a plpgsql level without having to throw them into
creating datatypes with C. This is very important
because it explodes the object capabilities of
postgres exponentially. That is why it was designed
that way in the first place--to use objects in a relational
database.

There has been very slow adoption of OR. One of PostgreSQL's
reasons (Illustra and informix had other reasons) is that
you always have to go down to C to do complex things.
Obvious and easily understood complex features like composite
data types should have always been supported at a higher level.

I'm not trolling for a R vs. OR flamefest or criticizing
the decision. I do understand the technical issues
involved. However, from an advocacy and usablity and
feature rich point of view this particular feature is
valuable IMHO.

Sorry to join the discussion so late.

elein

On Sat, Jan 03, 2004 at 12:31:10AM -0500, Tom Lane wrote:
> "Chris Travers" <chris(at)travelamericas(dot)com> writes:
> > AFAICS, there are only one thing missing and it could probably be worked
> > around if the backend did nto crash when you try to retrieve the information
> > via a casting function. It is:
> > Some way to define a standard input and output representation (how it is
> > done in C).
>
> Actually, we could very easily punt on that, instead saying you have to
> select out individual fields or else write your own formatting function.
>
> The thing we are missing (i.e., what makes it crash) is an internal
> representation that allows a tuple to be embedded as a field of a larger
> tuple. I've looked at this a couple of times, and each time concluded
> that it was more work than I could afford to spend at the moment. The
> support-such-as-it-is for tuple return values uses a structure that has
> embedded pointers, and it doesn't make any effort to get rid of
> out-of-line TOAST pointers within the tuple. Neither one of those
> things are acceptable for a tuple that's trying to act like a Datum.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)