# [patch] PDO_FETCH_KEYS

- Thread: https://externals.io/message/33418
- Original archive: https://news-web.php.net/php.internals/33418
- Started by Hans-Peter Oeri on 2007-11-24T21:31:30+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #33418 — Hans-Peter Oeri — 2007-11-24T21:31:30+00:00

URL: https://externals.io/message/33418#33418

Hi!

I discovered that PDO::FETCH_KEY_PAIR does not work as documented.
Documented is:
'Fetch into an array where the 1st column is a key and all subsequent
columns are values'

Actually, all but two column result sets throw an error...

Then I thought about generalizing the fetch mode. Have 1..n 'key'
columns. If only one value is left, assign it as a scalar. If multiple
columns are left over, have it taken as FETCH_ASSOC.

Please find attached a humble suggestion to generalize FETCH_KEY_PAIR to
FETCH_KEYS, including an attribute to define the number of 'key' columns
(defaults to one).

The result should be fully backwards compatible.

Please give me your suggestions.

HPO

PS: My diff includes my 'old' FETCH_2D patch.

---

## #33471 — Wez Furlong — 2007-11-27T19:40:41+00:00

URL: https://externals.io/message/33418#33471 · In reply to: #33418

What purpose does this serve exactly?
Why do we need to allocate an empty string for every database  
connection?
Why do we need this in the core?
There's a lot of manipulation being done here that is better suited to  
happen in PHP script land where it's safer and easier to maintain.

--Wez.


>
> @@ -1496,6 +1513,7 @@
> 	memset(dbh, 0, sizeof(*dbh));
> 	dbh->ce = ce;
> 	dbh->refcount = 1;
> +	dbh->nullbase = estrdup( "" );
> 	ALLOC_HASHTABLE(dbh->properties);
> 	zend_hash_init(dbh->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
> 	zend_hash_copy(dbh->properties, &ce->default_properties,  
> (copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
> diff -u -r1.118.2.38.2.24.2.7 pdo_stmt.c

---

## #33473 — Hans-Peter Oeri — 2007-11-27T20:16:31+00:00

URL: https://externals.io/message/33418#33473 · In reply to: #33471

Hi!

Wez Furlong wrote:

> What purpose does this serve exactly?

PDO::FETCH_KEYS is supposed to be a "generalized" form of the existing
PDO::FETCH_KEY_PAIR. The latter is limited to two column results and
organises it into key=>value.

PDO::FETCH_2D is an IMHO better strategy than the existing
ATTR_FETCH_TABLE_NAMES. The latter includes two "information tokens"
into one datum (the array index).

> Why do we need to allocate an empty string for every database connection?

The empty string is the default value for the attribute. `NULL` actually
has a different meaning. Of course, the actual implementation of a
default value is open for change, of course.

> Why do we need this in the core?
> There's a lot of manipulation being done here that is better suited to
> happen in PHP script land where it's safer and easier to maintain.

PDO::FETCH_2D is *NOT* easily implemented in PHP as it needs information
unavailable before.

PDO::FETCH_KEYS is just a generalization of the existing
PDO::FETCH_KEY_PAIR.

What do you mean by "manipulation"? I only intended to implement fetch
modes I need.

HPO

PS: Please notice the updated patch.