> > > I had a request on the PR[1] to rename the const, from PDO::PARAM_FLT to > > PDO::PARAM_FLOAT. Agree that readability is better here. Since there's > been > > a change, I'll plan on opening the vote tomorrow. > > Are you kidding me?
> You can't possibly think that changing the constant name resets the > cooldown counter. I don't. I posted a new version of the RFC on May 1st. These are the notes I sent to this list: Most of the discussion in the last round was about fixed precision types. > Since there was a lot of disagreement around the right way to handle them, > I'd like to keep them out of this RFC. I know Matteo wanted to get them > into this RFC, but I'd rather do less if it increases the chances that a > group can agree. Nothing in this RFC should interfere with a future > implementation of fixed precision types. > I added a PR to show how this feature would be implemented. It should make > it clear that very little change is needed to open up this functionality. I > avoided mixing in type casts or any special formatting to keep things safe > and simple. This allowed me to streamline the examples in the RFC quite a > bit. > It would be helpful to get feedback from anyone who voted "no" previously, > but didn't comment in the thread. There's no need to talk through this RFC > again if everyone in that group wants fixed precision types to be included. I think this changes the substance of the proposal, in which case there wouldn't need to be a cooldown period. It's okay if you disagree, but you can say so much instead of accusing me of acting in bad faith. I don't know how my emails come across. I apologize if I seem antagonistic. I'm not trying to rile you up. I'm just an engineer trying to figure out how to solve a technical problem. And I'm trying to get a solution that will please as many people as possible, including you. You could quite easily work around it by embedding your floats in the > SQL command string instead. Which is basically what emulated prepares > would do for you. > Yes, that would generate the right query, but it could make it difficult to improve its execution plan in the future. For example, I'm looking into an approach that would bring real prepared statements to pdo_dblib: https://bugs.php.net/bug.php?id=74592 If float parameters aren't bound, each value would result in a new execution plan, which would negate a lot of the benefit of having prepared statements. I kept these kinds of details out of the RFC on purpose. I have my use cases, but the maintainers of the other drivers should decide how they want to handle floats. I just want to add the hook so the information is there if anyone wants to use it. Thanks, Adam
