Re: TOAST (was: BLOB)

wieck(at)debis(dot)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