Re: Coping with 'C' vs 'newC' function language names - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Coping with 'C' vs 'newC' function language names
Date
Msg-id 13119.974479932@sss.pgh.pa.us
Whole thread Raw
In response to Re: Coping with 'C' vs 'newC' function language names  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Coping with 'C' vs 'newC' function language names
Re: Coping with 'C' vs 'newC' function language names
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Couldn't the function handler detoast the values before handing them to
> the function?  That would be slower, but it would allow people to continue
> to use the "simpler" interface.

This would be a moderately expensive thing to do --- not impossible,
but relatively expensive.  The old-style function handler would need
to look up all the function-argument datatypes during fmgr_info()
so that it could save a bool array telling it which argument positions
need detoasting.  (You can't just detoast every Datum --- you have to
at least verify that it's of a varlena type first.)

On a per-invocation basis, however, it probably wouldn't be very costly.

I didn't want to do this during development, but now that there are no
more old-style internal functions left, I suppose you could make a good
argument that this is worth doing for old-style dynamically loaded
functions.  Will put it on the to-do list.

Are people satisfied with the notion of requiring an info function
to go with each dynamically loaded new-style function?  If so, I'll
start working on that too.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Varchar standard compliance
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Coping with 'C' vs 'newC' function language names