From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Jan Wieck <janwieck(at)Yahoo(dot)com>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Coping with 'C' vs 'newC' function language names |
Date: | 2000-11-17 16:52:12 |
Message-ID: | 13119.974479932@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-11-17 17:02:19 | AW: Coping with 'C' vs 'newC' function language names |
Previous Message | Tom Lane | 2000-11-17 16:27:53 | Re: Varchar standard compliance |