On Fri, Feb 12, 2016 at 5:06 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > I think that this option is too much bother for the small internal purpose > at hand.
Yeah, I'm really frustrated with this whole thread. There's been a huge amount of discussion on this patch, but I don't really feel like it's converging towards something I could actually commit. For example, I just realized that this patch allows values to be either a double or an integer and extends the operators to handle double values. But variables can still only be integers. Please name any programming language that has such a restriction. The only ones I can think of are command shells, and those at least flatten everything to string rather than integer so that you can store the value without loss of precision - just with loss of type-safety. I think designing this in this way is quite short-sighted. I don't think variables should be explicitly typed but they should be able to store a value of any type that expression evaluation can generate. Also, as I said back in November, there's really two completely separate enhancements in here. One of them is to support a new data type (doubles) and the other is to support functions. Those should really be separate patches. If neither of you are willing to split this patch, I'm not willing to commit it. Going over half of this patch at a time and getting it committed is going to be a lot of work for me, but I'm willing to do it. I'm not willing to go over the whole thing at once - that's going to take more time than I have, and produce what will in my opinion be an inferior commit history. If somebody else is willing to commit the whole thing as one patch, I'm not going to object, but I won't do it myself. I would not worry too much about the list thing at this point. I'm sure something simple is fine for that. I actually think the patch is now in decent shape as far as code-cleanliness is concerned, but I'm not sure we've really looked hard enough at the design. For example, I find implementing operators as functions in disguise not to be one of PostgreSQL's most awesome design decisions, and here we are copying that into pgbench for, well, no benefit that I can see, really. Maybe it's a good idea and maybe it's a bad idea, but how do we know? That stuff deserves more discussion. Code cleanup is good, so I do think it's good that a lot of effort has been put in there, but I don't think more code cleanup is what's going to get this patch over the finish line. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
