Hi! I'm surely not the only one that ran into the problem of queries returning several columns with identical names. I didn't find anything about my following suggestion in the archives - if however, I'm only warming up old cheese, please ignore/bash me ;)
As I see, there is an connection attribute ATTR_FETCH_TABLE_NAMES that - depending on driver support - qualifies column names: column 'a' on table 'b' => $result['b.a'] Given support for that attribute, a FETCH_ASSOC returns a one-dimensional array with qualified column names. However, I don't consider this solution as good as it could be... E.g. it's rather hard to extract the values from a specific table (short of running over the whole index array). There is useful information "hidden" in the text... I therefore suggest a fetch mode that returns TWO-DIMENSIONAL arrays, the first dimension being the table/relation name, the second the column identification: column 'a' on table 'b' => $result['b']['a'] Such a solution would ease a lot of my 'framework' tasks. Open questions/ideas: - columns not originating from a table? Those could be entered in the first hierarchy (possibility of conflict with table names): $result['computed_value'] or in sort of a 'pseudo table' like '0' or 'unknown' (possibility of conflict by that pseudo name): $result['unknown']['computed_value'] - separate fetch mode or mode modification flag? There could be uses for a modified FETCH_BOTH as well, with column numbers all on first level plus hierarchical FETCH_2D. - what about a hybrid fetch? There could be uses for sort of a hybrid fetch, which would result in FETCH_ASSOC (each column name only once, first level) plus FETCH_2D (all columns hierarchically). To reduce memory consumption, the "doubly represented" columns could share a Z_VAL reference. Compatibility issues: - A quick glance only reveals fetchColumn and getColumnMeta as obvious compatibility issues. Should they be enhanced to not only accept column numbers, but textual column identifiers as well... - A hybrid mode (see above) that works 1:1 with existing code plus offers the advantages of hierarchical access would only be feasible with 'hidden' keys. I don't think that's necessary. What do you think? HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
