> -1. double is an inexact type, whereas integer is an exact type.
Sure. I already argue on that very line.
> The typical way to handle this sort of thing is to define a struct
> whose first member is a type field and whose second field is a union
> of all the types you need to care about.
Yep.
> Then that gets passed around everywhere. This patch should be designed
> in such a way that if we eventually end up with functions that have 10
> different return types instead of 2 different return types, we don't
> need to add 8 more parameters to any functions. Instead, those still
> return PgBench_Value (or whatever we call it) which is the
> aforementioned struct, but there are more options for what that can
> contain.
I just put the double type as a proof of concept, but for pgbench only
integers really matters.
What you suggest would work, but it would also result in ugly and lengthy
code, as I argued in another mail, because you have to decide for
overloaded operators and functions which actual typed operator must be
called, and then perform the necessary type conversions depending on the
actual type of the operands. The implicit descendent typing used in the
patch hides this, and is more than enough for pgbench, IMO.
If this is a blocker, I would rather remove the support for doubles than
write verbose and inelegant code.
--
Fabien.
