On 11/10/16 16:00, Adam Baratz wrote: >> I've had a quick look at the bug fix, although I haven't tested it. By >> > the looks of it, it seems that the third parameter has become mandatory, >> > which to me seems unacceptable. >> > >> > I would say that the type parameter should have precedence over the >> > actual PHP type only when it is explicitly passed. > > PDO::PARAM_STR is documented as the default value. I'd worry about adding > nuance to the API, potentially creating more edge cases. > > Another option would be to assume that all types are nullable. That is, if > a zval IS_NULL, quote in SQL as "NULL" regardless of the specified type. > Doing so would mean I could revert the test changes I made. The API would > be a little less doctrinaire, but probably more practical.
The importance of 'null' in relation to SQL data sets is something that PHP seems to push under the carpet a bit. It is essential to the way SQL works and so needs to mirror properly which trying to emulate something without having the correct metadata defining each field is only ever going to be a guess? You have to 'assume' when in reality PDO has always needed a proper schema facility either back from the connected database, or internally in order to 'emulate' the correct set of data. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
