Tom Lane wrote:
>
> Seems unlikely that that code could have worked either way, since you
> forgot to mark type uint2 as PASSEDBYVALUE...
>
Aargh! Thanks! Yes, when implementing it in the backend, that was just a
field to fill in, so I did it there. All seems well now.
One ends up with a vast number of combinations of types combinations for
different operators. As C takes care of the conversions, I wrote a
30-line perl script to generate me nearly 1600 lines of C for all the
type combinations (+ ~1700 lines of sql to define the
functions/operators). I cannot help feeling that that is not the right
way: if it can be done in a few lines of perl and relies on C cross-type
operations underneath anyway, it seems wrong to have to generate all
this code.
The problem is that there is not a clean hierarchy of SQL types, but for
many cases one could either convert the operands to int4 or float8 and
then numeric(?) and then convert back. At least the conversion operators
check for overflow, which is better than the current situation. And
precision wise it cannot be much worse: after all, large integer
constants already end up as floats. Is the SQL standard pedantic about
this?
BTW I could not find the discussion on entry-points to shared libraries
that Thomas mentioned. I've got some rushed dead-lines at the moment, so
I will not be able to look at anything for the next 3-4 weeks though.
Adriaan
