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

"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