Hello, sorry for the silence. At Fri, 18 Sep 2015 20:35:48 +0200 (CEST), Fabien COELHO <coe...@cri.ensmp.fr> wrote in <alpine.DEB.2.10.1509182019100.27223@sto> > > -1. double is an inexact type, whereas integer is an exact type. > > Sure. I already argue on that very line.
Agreed. > > 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. I also agree this. > If this is a blocker, I would rather remove the support for doubles > than write verbose and inelegant code. I understood the situation and agreed for current shape of the code. I no longer object the calling-alternatively code. But I'd like see the abbreviated discussion in the comment on the function. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
