Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> As I commented before, I would like to think about a different solution
>> to the fmgr problem for 6.6,
> Yes. I would love to see your solution!
I posted some preliminary ideas to the hackers list on 6/14/99 (see
message titled "Cleaning up function interface"). I think the fmgr
interface is in need of thorough redesign. Aside from the portability
bugs that we are currently getting our noses rubbed in, it cannot handle
NULL function arguments or results properly.
Something I didn't talk about in my earlier message, but am getting
more interested in doing: I would like to see if we can't make float4
a pass-by-value type, and float8 and int8 as well when on a platform
where Datum is 8 bytes wide. 64-bit platforms are going to become
the norm over the next few years, and Postgres shouldn't be forever
tied to palloc() overhead for passing and returning datatypes that
don't need it on newer platforms. I think that with suitably chosen
macros for accessing and returning function arguments/results, it
would be possible for the bulk of the source code not to be aware of
whether a particular C datatype is pass by value or pass by reference
in the fmgr interface.
In short, I think there are enough reasons for redoing the fmgr
interface from scratch that we ought to just bite the bullet and do it,
tedious though it will be.
The only real argument against it is that it'd break existing user code
in loadable libraries; people with user-defined functions written in C
would have to revise 'em. That's certainly a bad negative, but I think
the positives outweigh it. That existing user code will need to
change anyway to be ported to one of the platforms where parameter-
passing problems exist :-(
> BTW, What about HP-UX? Are they having similar problems with -O2?
On the newer 64-bit machines, I wouldn't be at all surprised. But
Mike Schout just reported regression tests passing on his 64-bit box,
so maybe we're still OK there. For now anyway...
regards, tom lane
