-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.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to