Thread: question about new fmgr in 7.1 snapshots
i've started playing with the 7.1 snapshots to try out the toast support. now it looks like i'm going to have to change a bunch of C functions that i have that call internal postgres functions, which didn't seem to be a problem (other than some extra typing) but my question is whether i should change the function to use the new fmgr type of definition or if it's only for internal functions. i'm not really clear on what the change does to how the user defined functions are handled. -- Jeff Hoffmann PropertyKey.com
Jeff Hoffmann <jeff@propertykey.com> writes:
> my question is whether i should change the function to use the new fmgr
> type of definition or if it's only for internal functions.
Up to you. If you need any of the new features (like clean handling
of NULLs) then convert. If you were happy with the old way, no need.
A new-style dynamically loaded function must be defined as using
language "newC" not "C"; this cues fmgr which way to call it.
Gotta start updating the documentation soon ;-)
regards, tom lane
Tom Lane wrote: > Jeff Hoffmann <jeff@propertykey.com> writes: > > my question is whether i should change the function to use the new fmgr > > type of definition or if it's only for internal functions. > > Up to you. If you need any of the new features (like clean handling > of NULLs) then convert. If you were happy with the old way, no need. > > A new-style dynamically loaded function must be defined as using > language "newC" not "C"; this cues fmgr which way to call it. > Are you sure on that? Doesn't TOAST mean that any user defined function recieving variable size attributes must expect them now to be compressed or stored external and change it's access to them going throughthe untoasting? Or do you do that for old style 'C' functions all the time in the fmgr now? > Gotta start updating the documentation soon ;-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck <janwieck@Yahoo.com> writes:
> Tom Lane wrote:
>> Jeff Hoffmann <jeff@propertykey.com> writes:
>>>> my question is whether i should change the function to use the new fmgr
>>>> type of definition or if it's only for internal functions.
>>
>> Up to you. If you need any of the new features (like clean handling
>> of NULLs) then convert. If you were happy with the old way, no need.
> Are you sure on that? Doesn't TOAST mean that any user
> defined function recieving variable size attributes must
> expect them now to be compressed or stored external and
> change it's access to them going through the untoasting?
If you have a user-defined function that takes a potentially-toasted
argument, you'll have to fix it to detoast its argument. I don't
think it's appropriate to saddle fmgr with that responsibility.
At least in theory, you could detoast the argument without also buying
into the new fmgr notation, but I agree that converting is easier ;-)
regards, tom lane