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 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 #
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