ext/pdo: Fix various bugs related to PDORow

[Girgias]

Easier to review commits in order.

[SakiTakamachi]

Thank you, the commits were separate and easy to read. Looks good to me as a change to this problem.

However, I discovered a use case like this:

$pdo = new PDO();

$stmt = $pdo->prepare('SELECT 1 as "3", 2');
$stmt->execute();
$result = $stmt->fetch(PDO::FETCH_LAZY);

var_dump($result, $result->{3}, $result[3]);

result:

object(PDORow)#3 (3) {
  ["queryString"]=>
  string(18) "SELECT 1 as "3", 2"
  ["3"]=>
  int(1)
  ["2"]=>
  int(2)
}
NULL
NULL

The solution is to fallback from row_read_column_number to row_read_column_name, but I'm not sure if I should support such behavior...
(Typically, no user would be bothered by not supporting this.)

notes: If nothing is specified for $stmt->fetch(), overwriting will occur due to duplicate keys in the array. However, this is not a big problem as we can use PDO::FETCH_ASSOC.

[SakiTakamachi]

There are cases like this.

$stmt = $pdo->prepare('SELECT 1, 2');
$stmt->execute();
$result = $stmt->fetch(PDO::FETCH_LAZY);

var_dump($result, $result->{1}, $result[1]);

object(PDORow)#3 (3) {
  ["queryString"]=>
  string(11) "SELECT 1, 2"
  ["1"]=>
  int(1)
  ["2"]=>
  int(2)
}
int(2)
int(2)

So there may be no point in fallback...

[SakiTakamachi]

Maybe we should consider this as a separate issue for now.

If it passes the test, I think it looks good.

[SakiTakamachi]

It's probably from the beginning, the tag one line above doesn't seem to be closed.

[Girgias]

Merged as b4e272c