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

Tue, 17 Oct 2000 11:20:04 -0500
Jeff Hoffmann <jeff@propertykey.com>
question about new fmgr in 7.1 snapshots
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

Tue, 17 Oct 2000 12:52:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: question about new fmgr in 7.1 snapshots 
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 through the  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 #



Mon, 23 Oct 2000 09:42:43 -0500 (EST)
Jan Wieck <janwieck@yahoo.com>
Re: question about new fmgr in 7.1 snapshots
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

Mon, 23 Oct 2000 11:30:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: question about new fmgr in 7.1 snapshots 