Обсуждение: 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