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