Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112620
MIME-Version: 1.0
References: <CAFv4g+G9k1vdi3F1Aj=UDK48dRBP6nZpSs4-aR36fUPR-8RLXw@mail.gmail.com>
In-Reply-To: <CAFv4g+G9k1vdi3F1Aj=UDK48dRBP6nZpSs4-aR36fUPR-8RLXw@mail.gmail.com>
Date: Sat, 26 Dec 2020 15:13:49 +0000
Message-ID: <CAGBsUrdtubTRfVtzn1-4RAXyL3AKqPwQyBj0gY4Xxqza3+h4dg@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Making mysqli easier to use with parameterised queries
From: tekiela246@gmail.com (Kamil Tekiela)

Hi Craig,

This is a great proposal, and I am delighted that someone is still
interested in mysqli and wants to improve it. I will discuss the
proposal below, but first some notes about the RFC itself:
1. mysqli_execute() is not deprecated despite what the PHP manual said
for the past 14 years. It is just an alias of mysqli_stmt_execute().
It's beyond me why we even have a separate page in the manual for that
alias. The mysqli documentation is in such a bad state that there are
lies/problems pretty much on every page.
2. Introducing mysqli::execute() would be a great idea, but the name
would be terribly confusing with mysqli_stmt::execute(). We need a
better name.
3. Please use syntax highlighting. I have already added that for you.

I like the proposal, and I think that having a shorthand notation for
prepared statement for one-time execution is a brilliant idea. The
implementation would not be too difficult, but it would obviously work
with mysqlnd only. This in itself is a problem. Ideally, we should
drop support for libmysql client but apparently some people think it
is still useful. We could emulate the same for libmysql but that would
make the implementation more complex.
Your implementation example in PHP has a major problem. The binding
types should never be guessed based on the value. The type is
specified by the column definition. Guessing the type will lead to
very undesirable behaviour. 99.99% of the time the values should be
bound as strings. If an explicit type cast needs to be performed by
mysqli then the long-way can be used instead.
Also, rather than binding the variables by reference explicitely, you
can use splat operator. This makes the implementation in PHP much
simpler:

class mysqli_rfc extends mysqli {
    function execute($sql, $parameters = []) {
// Preparing...
        $statement = $this->prepare($sql);
// Binding...
        if ($parameters) {
            $statement->bind_param(str_repeat("s",
count($parameters)), ...$parameters);
        }
// Executing...
        $statement->execute();

// Fetching mysqli_result or null (only with mysqlnd)
        return $statement->get_result();
    }
}

In C code, this could be easily achieved by creating a function that
is just a mash-up of all 4 of these functions. I think this would
definitely be a nice addition to mysqli, even though I doubt that it
will improve the state of mysqli code written by people. After all, we
can't force them to use parameter binding.

Regards,
Kamil

On Sat, 26 Dec 2020 at 11:23, Craig Francis <craig@craigfrancis.co.uk> wrote:
>
> Hi,
>
> Could the mysqli extension be tweaked to make parameterised queries easier?
>
> I've started an RFC at:
>
> https://wiki.php.net/rfc/mysqli_execute_parameters
>
> I'm going on the basis that some developers use mysqli directly, often
> because they want a small stand-alone script that has no dependencies, and
> the current mysqli extension doesn't exactly help them make the right
> choices.
>
> Craig