> > > I'd be most comfortable with this approach. I'd worry about adding a > > PDO::PARAM_NUMERIC type without investigating how it needs to function > for > > each DB, which feels like scope creep. If it starts off as an alias for > > PDO::PARAM_STR, there could be issues updating it to work correctly, > > especially if the right design involves modeling the precision > somewhere. I > > added a "Future Scope" section covering this. > > > > Let me know if there are major problems with this or other points to > cover. > > Otherwise, I'll aim to open voting on Monday. > > Let's just agree to disagree. I believe they should be investigated and > proposed in a single RFC. Having just one and relying on an obscure > documentation warning is not enough IMHO.
I looked more closely at each of the APIs. My conclusion was that a single type will be appropriate for floats, doubles, and fixed-precision. I updated the RFC with details. If it's accepted, it could be worth including some of this content in the documentation so people better understand the impact of each PDO param type. I'll create a separate thread to announce the vote. Thanks, Adam
