/79b59d958c43042e54348dfbae0b0c2509563aa7
which I declared as out of scope but could in fact be supported without
too much effort.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
a "now or never" situation.
It would feel a bit weird that the PDO class and its namespace are
spelled different (Pdo\Mysql).
ATM, I'm +0 on this.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
uoted".
Otherwise they will be passed according to what the database client
library needs (byte length + string, or any other format).
It's a good point and I'll make sure to add this to the RFC.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi,
On Wed, 17 Apr 2024, at 19:25, Kamil Tekiela wrote:
> I think the question here was more about what the syntax will be after the
> parameters are substituted. But if I recall correctly, the quoting is done by
> PDO:: quote so the syntax will remain the same. Only the buggy behavior would
>
ld be best in many circumstances.
As for recommending testing on SQLite when production is on MySQL, I've
always found that to be a (huge) foot gun. Of course YMMV ;-)
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
and SQL Server seem only to
understand double single quotes.
I agree we need more research, but it's already 4 database drivers we'd
be fixing by switching the default parser to standard SQL quotes.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
that it makes sense to have a parser for each driver.
Thanks for the feedback. I will reference this issue as duplicate too in
the RFC. I'm certain if we dig deep enough we'll find a few more.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Il 17/04/2024 15:38, Sergey Panteleev ha scritto:
Hi all!
Voting ended and Derick's script counted the votes [1].
Our "rookie" PHP 8.4 release managers are:
- Calvin Buckley
- Saki Takamachi
Our "veteran" is the PHP 8.3 release manager Eric Mann.
Congrats to the RMs!
Hello everybody,
I'd like to start a discussion on a new RFC about fixing the default PDO
SQL parser and having (optional) driver-specific parsers.
https://wiki.php.net/rfc/pdo_driver_specific_parsers
Thanks GPB and Tom de Wit for their help with initial proof-reading.
Cheers
--
Matteo
SERVER_GONE_ERROR,
UNKNOWN_SQLSTATE, mysqlnd_server_gone);
+ }
DBG_ERR_FMT("Can't read %s's header", packet_type_as_text);
DBG_RETURN(FAIL);
}
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
is certainly brilliant, but
the complexity is so big that I feel we should aim for a trimmed down
version to make it easier to grasp and to work with, e.g. less syntax
variants (no short or constructor promotion), and perhaps no virtual
properties.
Cheers
--
Matteo Beccati
Development & Consul
Hi Sebastian,
Il 14/03/2024 14:15, Sebastian Bergmann ha scritto:
Am 14.03.2024 um 14:07 schrieb Matteo Beccati:
In my daily CI I have several builds failing today, eg.
* PHPUnit 9.6
See https://github.com/sebastianbergmann/phpunit/issues/5719.
thanks, I had a quick look in the open
and
fix or report them.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
with the database standards.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
to be a full DB abstraction layer.
As such, it is not expected that all databases behave the same,
especially for exotic functionality, such as autocommit.
My 2c
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing
installer of a legacy open source software ;-)
Seriously though, I do agree with changing the default. I believe such
check was added in a time when it was still common to use the cgi
executable to run cli commands and the configuration was shared with
mod_php.
Cheers
--
Matteo Beccati
D
is going to cause BC problems, or
generate a whole new series of bugs and incompatibilities.
See:
https://bugs.php.net/bug.php?id=80892
https://github.com/php/php-src/pull/6801
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Develop
] to allow drivers to have their own SQL parser, but haven't
yet managed to find time to go through the RFC process.
References:
[1] https://externals.io/message/114016
[2] https://github.com/php/php-src/pull/6852
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
e transaction was not
actually active rather than relying on seemingly working code that
doesn't do what's on the tin.
In fact I probably never knew about this particular MySQL quirk and most
likely I had been fooled many times into thinking that the code above
was a single transaction.
ibe promising a phpday
elephpant in exchange ;-)
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
?
Regards,
Sergei Morozov
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
php?id=51499
Thanks for your consideration!
Daniel
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ve opened a bug report to keep track of it:
https://bugs.php.net/bug.php?id=80892
<https://bugs.php.net/bug.php?id=80892>
Thank you,
Benjamin
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
. >
[...]
Is there any reason why the pgsql driver doesn't respect PDO::PARAM_STR?
Looks like a bug to me. I thought this had been fixed a while back, but
apparently it wasn't. I'll try to find some time to investigate in the
next few days.
Cheers
--
Matteo Beccati
Development & Consulting
ub/smalyshev/php-src/builds/215525375 that
> looks fine.
likewise:
https://revive.beccati.com/bamboo/browse/PHP-SRC8-TESTS-897
Sorry it took a while as I broke the build script when PHP-8.0 was
branched and I hadn't had time to check and fix it.
Cheers
--
Matteo Beccati
Development & C
uick look when the diff is >16kb, an
attachement is generated instead (vs inline diff) and in my archive I
have emails hitting 250kb.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
it ;-)
I was just saying that some commits aren't getting to the php-cvs
mailing list, and often that happens when closing GitHub PRs. And I
suspect it has somethinig to do with the way the PR merge is handled.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP In
but maybe in those cases the git workflow from
our wiki page wasn't properly followed when merging pull requests?
https://wiki.php.net/vcs/gitworkflow
Today's example:
https://github.com/php/php-src/pull/5803
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
do/pdo_dbh.c#L1481
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
o3.php
Got rows: 65535
[Timings] prep: 0.018, exec: 0.210, fetch: 35.812
root@jameson /tmp # /tmp/php-7.4-opt bench_pdo3.php
Got rows: 65535
[Timings] prep: 0.019, exec: 0.208, fetch: 0.026
That's almost 36 seconds vs 26ms.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.be
Hi George,
/cc release managers - pls don't hate me ;-)
On 27/08/2020 10:23, Matteo Beccati wrote:
>
> On 26/08/2020 19:28, G. P. B. wrote:
>> This can still target PHP 8.0 as this seems to be akin to a bug this
>> might even be applicable to PHP 7.3/7.4. Anyways, good ca
?
https://github.com/php/php-src/pull/6047
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
, thanks.
I'll have a look into it, although I think anything we do in that area
would target 8.1.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
foot-gun.
I think it might have been used in some deb/rpm packages a very long
time ago and I vaguely recall it being somewhat a recommended setting
for performance.
I have however no recollection of when it stopped being relevant.
Cheers
--
Matteo Beccati
Development & Consulting - http:
or a PECL
> extension anymore, the benefit of this will be that the code is always
> up-to-date and can be build out of the origin source.
What you'd need would be someone to step up and start maintaining it. If
it doesn't currently work that's one more reason not to bundle in core.
Cheers
--
iewpoint, it would be preferable though.
To each their own. From my viewpoint, and possibly quite a few other's,
having two syntaxes is not preferable.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Hi Rowan,
On 17/08/2020 18:36, Rowan Tommins wrote:
> On Mon, 17 Aug 2020 at 16:21, Matteo Beccati wrote:
>>
>> FWIW, I've just been hit by https://bugs.php.net/bug.php?id=47021 in a
>> SOAP response from a server using "Transfer-Encoding:> spaces>chunked".
is still open, although the comments to
the PR hint to the fact that it should have been fixed.
This was on PHP 7.3.17, I'll see if I can build a self-contained test
case and reproduce with the latest from git.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
, since most of the times longer attributes will
still, albeit just visually, have some in the closing ")".
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e welcome ;-)
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
multiline attributes or inline
function definition.
Since '@@' is causing such unrest, I'd be happy to revisit my choice and
embrace '#[', which was the second option in my vote.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Developmen
-RPC
API, which depends anyway on a userland implementation and not on
ext/xmlrpc.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
; query is made.
>
> I believe it also brings the behavior inline with what developers would
> actually expect the default to be in modern PHP.
>
> Regards,
>
> AllenJB
>
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ngracefully at best, or corrupt data
> at worst.
>
> Changing a default like this seems a reasonably safe thing to do in a major,
> as long as it's still just as easy to switch back to silent mode for those
> who prefer to be explicit.
I agree defaulting to PDO::ERRMODE_EXCEPTION is a s
gt;
> Thoughts?
Thanks for bringing it up. I suppose it's about time to start conforming
to the SQL standards, but maybe we should have gone through a
deprecation stage first?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime De
a little less aggressive?
AFAICS Nicolas is creating his first RFC and has a patch for it that you
already have commented on on github, so I see no foul play here.
Besides, Symfony has left PHP-FIG a while back ;-)
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com
ad idea, having a warning
there> wouldn't hurt too.
I was about to give my +1 on the more generic approach, but type hints
could also be interfaces and "instance of the class X" is not a good fit.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
capable to configure the server as they please, without having to put
their code into a system directory.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 22/07/2019 11:11, Nikita Popov wrote:
> On Mon, Jul 8, 2019 at 2:08 PM Matteo Beccati wrote:
>
>> Hello everybody,
>>
>> I've just opened the vote on
>> https://wiki.php.net/rfc/pdo_escape_placeholders
>>
>> voting will close in two weeks, on Ju
Hello everybody,
I've just opened the vote on
https://wiki.php.net/rfc/pdo_escape_placeholders
voting will close in two weeks, on July 22nd.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
Hi Nikita,
> On 5 Jul 2019, at 12:37, Nikita Popov wrote:
>
>> On Tue, Jul 2, 2019 at 8:22 PM Matteo Beccati wrote:
>> Hi Nikita,
>>
>> On 02/07/2019 15:07, Nikita Popov wrote:
>> > Friendly reminder that this RFC needs to go into voting until M
ink that
> a) the need for a literal \? seems rather rare and b) double-escaping is
> already a well-understood problem for anyone who ever used regular
> expressions.
Fair enough. Tbh, I have no strong preference... Would "\?" require also
implementing escape of the escape? Would th
rators.
No word boundaries involved. Any occurrence of "??" outside comments
will be translated into "?", so that operators containing the "?" ("A ?|
B", "A ?& B") can be used. If one had defined both "?=" and "??=", they
would need to be escaped in PDO as "??=" and "=".
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
syntax I think such changes are unwise.
Could you please elaborate?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
accepted!
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
persistent datastores it's a good idea to
review them to make sure you handle exceptions right away, but otherwise I
wouldn't be overly concerned.
Thanks Nikita that's much clearer to me now.
I'm not as concerned as this is much different from "bad things will
happen" ;)
Cheers
--
Matt
any sense of
urgency.
Since there are many people who can vote and only do PHP userland, I
believe that clarifying impact on the RFC itself would surely benefit
everyone. Suggesting that they shouldn't vote is definitely not helping.
My 2c.
Cheers
--
Matteo Beccati
Development & Consulting - http://
Hi Christoph,
On 14/05/2019 16:13, Christoph M. Becker wrote:
On 14.05.2019 at 15:52, Matteo Beccati wrote:
How would the change affect extension developers?
See <https://wiki.php.net/rfc/tostring_exceptions#extension_guidelines>.
Perhaps the section can be expanded to illustrate
ort.
How would the change affect extension developers?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
its bundled
Smarty lib fork.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Nikita,
On 08/04/2019 10:36, Nikita Popov wrote:
On Wed, Apr 3, 2019 at 2:48 PM Matteo Beccati <mailto:p...@beccati.com>> wrote:
I've identified two different kinds: one in zend_assign_to_variable and
the other one during shutdown. Here are the backtraces:
.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ut
not used [-Wunused-function]
static void iface_append_unicast(zval *unicast, zend_long flags,
^
*** Error code 1
I'll see if I can get them fixed in the next few days.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime
ted prepares,
> and in EasyDB we go out of our way to disable this feature.)
I'm not opposed to a new method, but I think it would be confusing.
Moreover with safeQuery you'd miss all the possibilities to bind
parameters etc, offered by PDOStatement.
Cheers
--
Matteo Beccati
Development & C
ses libpq's own
PQexecParams function.
At that time I had checked if libmysqlclient offered a similar function,
but it didn't seem like it, so I went for the pgsql-only constant.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Devel
OB field type support lands in PDO_sqlite as
well soon after.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e underlying datbase.
Seeing the RFC, I gave for granted that SQLite couldn't use the standard
LOB api provided by PDO, but maybe that isn't the case? I'll leave the
OP to reply.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Dev
as been using when
providing something that's relevant only for a specific driver. Such
methods should be used with caution.
What's your suggestion?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
born to allow quickly writing
database drivers, not as an abstraction layer that allows you to
seamlessly move from one another. I thought the same but I was corrected
by someone that was involved in the process.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PH
On 19/05/2017 14:35, Matteo Beccati wrote:
> [0x716801e0] bool: false
>
> It's not an empty string.
My mistake, I ran the wrong example test script through the debugger. It
is an empty string, sorry.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.
Hi Dorin,
On 18/05/2017 12:17, Matteo Beccati wrote:
> Hi Dorin,
>
> On 18/05/2017 11:41, Dorin Marcoci wrote:
>> I meant the case when a bool is passed as string, like
>> bindValue('boolparam', false);
>> Here it comes as an empty string, not "0", whil
> conversation is a waste of time for both of us.
As it is now, I'm afraid not.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
about its
usage in the wild, i.e. I don't know how many ORMs, abstraction
libraries, etc are using the feature and could suddenly break or just
throw deprecation notices all the time.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtim
re it comes as an empty string, not "0", while true comes as "1".
Please have a look again at my example and the code I linked. How could
it work if what you say is true?
Please note that the code is in the PDO_PARAM_EVT_EXEC_PRE case.
Cheers
--
Matteo Beccati
Development
shows that the pgsql driver is
working, so maybe you could have a look at how it works.
e.g.
https://github.com/php/php-src/blob/master/ext/pdo_pgsql/pgsql_statement.c#L382
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Develop
on plan, which would negate a lot of the benefit of having prepared
> statements.
Since your driver uses emulated prepares, I'd expect you having a new
execution plan regardless. At least for current master, which is the RFC
target.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e going to save?
I would agree that NULL is not a type and the constant shouldn't have
been there in the first place, but I think it could be a bit too late now.
The proposal itself is rather evil: it would break lots of code (a quick
github search shows 95k+ results) for basically no gain. Or maybe
AM_STR.
Config flags are evil as it's one more thing you'd need to be aware of
and could change depending on the environment you run your script or
library on.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e to reply.
FWIW, I still think that both _FLOAT and _AUTO are very bad ideas.
About _NULL, I'm just worried about the potential BC break caused by the
sudden deprecation, for a little-to-none gain. But I haven't looked the
issue into much detail.
Hopefully I'll have more time in the next few days
use more issues for anyone else not using pdo_dblib.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
d
> "no" would change their minds if fixed-precision was simply left out of
> scope.
I don't know, but I wouldn't as I've already explained a number of
times. If anything, what I see is that very few care.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccat
or of something
> supported by Microsoft, but the timeline for that is unclear.
Cool, thanks for the clarification.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a tiny portion of our users.
While I'm at it, could you please clarify the following for me: Why is
there so much effort devoted to the legacy dblib driver when pdo_sqlsrv
seems a much better replacement on paper? Googling for info didn't help,
so there surely must be something I'm missing here.
Chee
e floating point type is appropriate
for both fixed-precision and floating points seems ill-advised, as is
probably the API you are basing your decisions off of.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing L
on an obscure
documentation warning is not enough IMHO.
Even your RFC claims that it should be used for numeric types :(
"This test was repeated using the numeric type for the number column."
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi Andrea,
On 11/04/2017 19:25, Andrea Faulds wrote:
> Matteo Beccati wrote:
>> a PDO::PARAM_NUMERIC const that could in fact just be an alias for
>> PDO::PARAM_STR for most of the drivers
>
> This is a technical solution to a documentation problem.
Yes, and I'd tend to a
y suggestion of a PDO::PARAM_NUMERIC const that could in fact
just be an alias for PDO::PARAM_STR for most of the drivers.
The most important thing to me is to discourage the misuse of
PDO::PARAM_FLOAT for types that are not actually floating points.
Cheers
--
Matteo Beccati
Development & Consu
hould also
add PDO::PARAM_NUMERIC in order to avoid mistakes?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
as wondering why you didn't vote just yet and here's the answer.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
replicating that in DBAL.
I'm sorry, I think it's too disruptive both for userland and drivers
developers. For very little gain, if I may.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
encoding
(Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
match the internal encoding of the driver (e.g. UTF-16?)? What happens
if I try to quote a latin1 string?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ester 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
>> Ra
ble.
My biggest worry is its potential misuse for decimal fields. I know this
isn't reason enough for denying an improvement, but there are already
too many people mistakenly using double for currency data and monetary
calculations...
That said, I think this more than anything else require
ause loss of precision.
> Is there a reason PDO::PARAM_DOUBLE doesn't exist?
I don't know if there's am historical reason. I think it should be
there, but to be honest, I'm not sure it's worth the effort at this point.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.becca
t 7.1.x.
Could you please revert? Albeit minor, it's a new feature and therefore
it belongs to 7.2.
We shouldn't try to arbitrarily squeeze things into stable releases.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Developme
C. Anyone could create a new RFC
to add array output to debugDumpParams, that would be most welcome.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ldn't it be better to
> return a structured array with the information needed? If needed, you
> can var_dump() the array yourself.
Could you please explain what's the use case? As far as I'm concerned
such information would only be useful during PDO driver development,
phpt files and bug rep
SQL: [%zd] %.*s\n",
>> stmt->active_query_stringlen, (int) stmt->active_query_stringlen,
>> stmt->active_query_string);
>> }
>
>
> Let me know what you think of this approach. If it sounds fine, I'll update
> the RFC.
Possibly, but tbh I haven't had
RE x = 'foo'"
(only available after execute)
For consistency, I would prefer to only add the information after
execute() has been called.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that's a good idea.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 260 matches
Mail list logo
