Description: ------------ add an option to nextId(), to lookup the databases default nextID eg. as defined by id int(11) default nextval(mysequence), .... - it is known to be possible in postgres....

Wouldn't an extra argument cause difficulties for people moving from pgsql to another driver?

Should be ok - other databases can just ignore the value. they would just fall back to non-native sequences.. I guess the main reason is that if a database is used by other applications - eg. perl.. VB or something.. they can be updated independantly. I would prefer it to be returned by tableinfo as well..

Yeah, I guess we could add the argument to the sequence methods in all of the drivers. I'm now looking at pgsql.php. It does use native sequences. createSequence() does a CREATE SEQUENCE and nextID() calls SELECT NEXTVAL(). This should always return a unique ID, even when multiple sessions are in use. Here's the documentation: http://www.postgresql.org/docs/current/interactive/sql-createsequence.html Can you elaborate on what you mean, please? By "prefer it to be returned by tableinfo as well" you mean you'd like the method to be able to indicate if a column is auto-incremented? I've been gradually cleaning up and testing the tableInfo methods. I'll add this type of column into the mix and see what can be done with it.

native as in defined as the default value for a column.. eg. id int(11) default nextval(mysequence), unless you manually specify 'mysequence' for the sequence - you are likely to create a different sequence (normally {tablename}_seq acutally for table info on the above example - it should returb something like [name] => 'id' [type] => 'int(11)' [sequence_name] => 'mysequence' ....

Hi Alan: Pardon my delay in getting back to you on this. Can you please provide a patch that implements what you're thinking? Thanks.

No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.

This should really just hang open, as it's a feature request. - that no-one has had the time to implement...

You're quite right, and I apologise -- No Feedback was clearly the wrong resolution. That being said, given the deprecated, maintanance-only state of DB, I'm still not really sure this should remain open; perhaps it would be better off as an MDB2 issue, since at an admittedly cursory glance, it looks like MDB2_Driver_pgsql doesn't yet have this feature either. Given your status as a PEAR Group member, Alan, you're probably better placed to make the decision than I am as a new maintainer -- should we implement it in DB in spite of its deprecation (in which case I'll look at it in after the 1.7.7 release, which should be next week), or morph this into an MDB2 bug? (Alternately, should I raise the question on PEAR-DEV?)

Per an IRC discussion with Alan, this request is Won't Fix for DB, and request #9762 has been filed for the same functionality in MDB2.