Re: TOAST (was: BLOB)

wieck@debis.com (Jan Wieck) writes:
>> What I meant was that they'd still work, with a limit on field size,
>> just like before.  ie, no TOAST support.

>     Yes, but at the first time, a toasted value is handed to them
>     the result (up to backend crash)  is  unpredictable.  So  any
>     user   defined   function   taking   "text"  as  argument  is
>     potentially in danger!

Oh, right, user-defined functions on system types will have problems
if the system type has been marked toastable.  I was thinking of
user-defined datatypes, for which it'd be OK to leave the type
untoastable if you didn't want to fix the associated functions right
away.

>     Better tell them they have to revise.

Well, hmm.  It's not out of the question that we could continue to
support old user-defined functions even on toastable types.  There is
going to be a compatibility wrapper anyway around any function that's
adhering to the old fmgr interface.  So with just a little more work,
we could make that wrapper expand any toasted values that are being
presented to the function.  Only new-style functions would ever get
passed toasted values directly.

This'd also make it a lot less painful to convert the built-in
functions, of course.

The only downside I see in this is that it'd take a few extra catalog
lookups to determine which arguments are toastable types and thus
potentially in need of untoasting.  I don't think that'd be a big loss,
since we normally only do the catalog lookups for a function reference
once per query anyway.

Seem reasonable?
        regards, tom lane