PHP 8.1 PDO has been changed so that when MySQL returns an integer it
will no longer be returned as a string, but as an int.
The problem is this breaks any sites that use UNSIGNED ZEROFILL integer
fields in MySQL.
I support a number of websites where the phone numbers and post codes
are all
> On 27 Feb 2021, at 15:56, Matty The Mad wrote:
>
> PHP 8.1 PDO has been changed so that when MySQL returns an integer it will
> no longer be returned as a string, but as an int.
>
> The problem is this breaks any sites that use UNSIGNED ZEROFILL integer
> fields in MySQL.
>
> I support
Apologies, in respect of point 1 in my reply, I misread your original
message and didn't realise you were referring to the upcoming 8.1 change,
thought you were referring to the current 8.0.1 release.
This change AFAIK only affects emulated prepares and is an improvement, as
previously you needed
On Sat, 27 Feb 2021 at 14:00, Rowan Tommins wrote:
> Hi all,
>
> I would like to propose we formally deprecate the function debug_zval_dump
> and remove it in PHP 9.0.
>
> This function is mostly similar to var_dump, with the additional ability
> to output the refcount of a variable. This has
On February 27, 2021 5:23:47 PM GMT+01:00, Kamil Tekiela
wrote:
>>
>> The issue is, as said, that this only happens in an error situation.
>> Thus if users only test "does my site still work after update?" (what
>> many do ...) won't notice this, till something fails, which would
>have
>>
> The code shown here https://www.w3schools.com/php/func_mysqli_connect.asp is
relatively correct at the moment. Maybe not nice, but it handles the error.
That is the second hit on google (after php.net manual) when searching for
"php tutorial mysqli_conect") Most other books, tutorials, ... teach
Hi Matthew,
As was pointed out before ZEROFILL is getting deprecated. It has been
deprecated by MySQL and I assume MariaDB will follow soon.
The change you are referring to is only to fix inconsistency in PHP. The
problem with ZEROFILL has been present since forever as far as I know.
The setting
On Sat, Feb 27, 2021 at 3:00 PM Rowan Tommins
wrote:
> Hi all,
>
> I would like to propose we formally deprecate the function debug_zval_dump
> and remove it in PHP 9.0.
>
> This function is mostly similar to var_dump, with the additional ability
> to output the refcount of a variable. This has
On Sat, Feb 27, 2021 at 5:24 PM Kamil Tekiela wrote:
> >
> > The issue is, as said, that this only happens in an error situation.
> > Thus if users only test "does my site still work after update?" (what
> > many do ...) won't notice this, till something fails, which would have
> > been caught
Hi Matthew,
1. PHP 8 has not introduced a change to PDO_MYSQL in respect of how values
are fetched. What makes the difference as to whether you get MySQL INT
values fetched as strings or integers is whether you are running PHP with
the mysqlnd https://dev.mysql.com/downloads/connector/php-mysqlnd/
Le 27/02/2021 à 14:18, David Gebler a écrit :
Apologies, in respect of point 1 in my reply, I misread your original
message and didn't realise you were referring to the upcoming 8.1 change,
thought you were referring to the current 8.0.1 release.
This change AFAIK only affects emulated prepares
On 27/02/2021 19:29, tyson andre wrote:
- Checking the difference between two runs is useful in a bug report - if
counts increase or decrease after calling a function
that isn't supposed to modify reference counts, this makes it an obvious
indicator for reference counting bugs that can be
On 27/02/2021 20:05, Nikita Popov wrote:
If we additionally change it to explicitly print reference wrappers, I
believe that debug_zval_dump() will produce a faithful representation.
Is that even possible without either accepting parameters by reference,
or taking a variable name like the
On Sat, Feb 27, 2021 at 10:12 PM Rowan Tommins
wrote:
> On 27/02/2021 20:05, Nikita Popov wrote:
> > If we additionally change it to explicitly print reference wrappers, I
> > believe that debug_zval_dump() will produce a faithful representation.
>
>
> Is that even possible without either
On February 27, 2021 7:29:43 PM GMT+01:00, Kamil Tekiela
wrote:
>> The code shown here
>https://www.w3schools.com/php/func_mysqli_connect.asp is
>relatively correct at the moment. Maybe not nice, but it handles the
>error.
>That is the second hit on google (after php.net manual) when
Your opinion is highly appreciated, Johannes. I feel that we will have to
implement this change as you are proposing.
I don't think I am rushing this change, because I believe is already late.
It should have been fixed in PHP 7 or PHP 8, but because very little people
use mysqli this extension
On Wed, 2021-01-27 at 15:17 +0100, Sebastian Bergmann wrote:
> Am 25.01.2021 um 11:03 schrieb Nikita Popov:
> > Fully support this proposal. Throwing exceptions is the right
> > default, it
> > matches what PDO does, and restoring the old behavior is one line
> > of code.
>
> I second that
Le 27/02/2021 à 15:39, Rowan Tommins a écrit :
On 27/02/2021 14:03, Pierre wrote:
I'm curious, why are you stating that emulated prepares are not
useful anymore ?
Emulated prepares are a slightly dangerous idea, because they give the
impression of separating query from data, but actually use
On Thu, 25 Feb 2021 at 08:35, Claude Pache wrote:
>
> Hi,
>
> In the paragraph “Difference between PDO and mysqli”, you propose:
>
> “Array keys are completely ignored. mysqli doesn't have emulated prepares
> nor does it have named parameters.”
>
> Instead of ignoring the keys, I think it is
On Sat, Feb 27, 2021 at 9:50 AM Matty The Mad wrote:
> PHP 8.1 PDO has been changed so that when MySQL returns an integer it
> will no longer be returned as a string, but as an int.
>
> The problem is this breaks any sites that use UNSIGNED ZEROFILL integer
> fields in MySQL.
>
> I support a
On 27/02/2021 15:51, Pierre wrote:
Yes, but PDOStatement::execute() explicitly documents that it can be
used only for prepared queries.
The same is true of bindParam and bindValue - the only way of using
parameters is to first "prepare" a query. Whether that's a real prepare
(on the
On 27/02/2021 16:57, Kamil Tekiela wrote:
If product_id is actually an integer column, this function is
technically broken: given a non-integer input, it will produce an
error
in the database.
I'm sorry, but I do not understand why would that code produce an
error. The value
Hi all,
I would like to propose we formally deprecate the function debug_zval_dump and
remove it in PHP 9.0.
This function is mostly similar to var_dump, with the additional ability to
output the refcount of a variable. This has always been hard to interpret, but
is now so complex as to be
On 27/02/2021 14:03, Pierre wrote:
I'm curious, why are you stating that emulated prepares are not useful
anymore ?
Emulated prepares are a slightly dangerous idea, because they give the
impression of separating query from data, but actually use string
escaping internally. Historically, I
On 27/02/2021 16:23, Kamil Tekiela wrote:
I don't see why this would be such an issue. If the code fails for any
reason then an error is produced. The error might be surprising, but it is
not something that would cause problems.
Just addressing this argument, not the proposal itself, a
>
> If product_id is actually an integer column, this function is
> technically broken: given a non-integer input, it will produce an error
> in the database.
>
I'm sorry, but I do not understand why would that code produce an error.
The value is properly escaped and formatted so there should be
On 27/02/2021 18:10, Kamil Tekiela wrote:
Select * From products Where product_id = 'hello world'
If product_id is a column of type int, then the database will raise an
error about incompatible types.
No, this query would produce a warning. I am unaware of an SQL mode
that would
Hi Rowan Tommins,
> I would like to propose we formally deprecate the function debug_zval_dump
> and remove it in PHP 9.0.
>
> This function is mostly similar to var_dump, with the additional ability to
> output the refcount of a variable. This has always been hard to interpret,
> but is now
>
> The issue is, as said, that this only happens in an error situation.
> Thus if users only test "does my site still work after update?" (what
> many do ...) won't notice this, till something fails, which would have
> been caught nice beforehand.
>
I don't see why this would be such an issue.
>
> Select * From products Where product_id = 'hello world'
>
> If product_id is a column of type int, then the database will raise an
> error about incompatible types.
>
No, this query would produce a warning. I am unaware of an SQL mode that
would turn this warning into an error. Maybe I am
On Tue, 23 Feb 2021 at 18:46, Rowan Tommins wrote:
> On 23/02/2021 18:21, Pavel Djundik via internals wrote:
> > See https://nigeltao.github.io/blog/2021/json-with-commas-comments.html
> > for more information.
> > ...
> > Perhaps this could be disabled by default and made opt-in with a
> >
31 matches
Mail list logo
