Re: Bug and/or feature? Complex data types in tables... - Mailing list pgsql-general

From Tom Lane
Subject Re: Bug and/or feature? Complex data types in tables...
Date
Msg-id 18914.1073107870@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug and/or feature? Complex data types in tables...  ("Chris Travers" <chris@travelamericas.com>)
Responses Re: Bug and/or feature? Complex data types in tables...  (elein <elein@varlena.com>)
Re: Bug and/or feature? Complex data types in tables...  (Michael Glaesemann <grzm@myrealbox.com>)
Re: Bug and/or feature? Complex data types in tables...  (Michael Glaesemann <grzm@myrealbox.com>)
List pgsql-general
"Chris Travers" <chris@travelamericas.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

pgsql-general by date:

Previous
From: "Chris Travers"
Date:
Subject: Re: Bug and/or feature? Complex data types in tables...
Next
From: Gaetano Mendola
Date:
Subject: Re: why the need for is null?