Hi! Thanks for your response!
Lukas Kahwe Smith wrote: >> Not sure how real world useful this is. What I have seen more is a I often run into a situation like the following: We need a "framework like" class to change *joined* tables. The framework itself has no inherent knowledge about table fields, but (anyhow) loads table definitions. This functionality is useful for: a) duplicate field names in different tables (FETCH_NAMED does not help) b) update tables, as - without any additional work - I have the fields "by table" Access to fields w/o knowing their table is possible by combining FETCH_2D with FETCH_ASSOC or FETCH_NUM. As that creates references, changes to "table-less" fields are represented in the "table" fields automagically ;) I don't know how often, but in "my" real world, that's bloody useful. But at least much more useful than the existing ATTR.FETCH_TABLE_NAMES... As for "empty string" index: In my proposal, you could: setAttribute( PDO::ATTR_2D_NULLBASE, '') Would your really like to *fix* it to that? > like I said ideally PDO would know about FKs and use those to build the > tree structure automagically. Any added *functionality* (defined by: PDO *knows*) must be sincerely discussed, I think. My proposal only adds a way to return fetched data - PDO does not *know* anything more. > I would like to see: > 1) lazy connect > 2) driver independent DSN support Please bear with me - I'm not a practiced coder. I'm sure my humble proposal contains many bugs... But why lazy connects? As for DSN: Has anybody discussed including username/password into the DSN? mysql:username:[EMAIL PROTECTED] HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
