On Wed, 03 Dec 2008 10:19:57 +0100 Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > D'Arcy J.M. Cain schrieb: > > The insert method hasn't returned the OID for a long time. The > > documentation is wrong. Let's fix that and move on. In fact I did fix > > that earlier today. > > > > Or did you mean that the OID isn't in the return dictionary? Is that > > an issue do you think? > > Not sure. It would be nice to have a way to get the OID back. Maybe we > can make the return_change an expression that will be used in the > returning clause, so we have full flexibility (it could then also be > renamed to "returning"). A value of True would be equivalent to "*".
Sounds like a good idea. Let's do that. For < 8.2 we can still do what we do now when returning is not False or empty. The critical thing will be to get the name right before January. > Also, I noticed that the behavior of insert(), update() and delete() is > not as consistent as it could be. For instance, update() can work > without an oid and work with primary keys instead, but delete() needs an > oid. And similar to insert(), update() could also make use of a > return_changes parameter and the returning clause. There is a danger of deleting multiple rows but perhaps that isn't our issue but rather the programmer's. This isn't a user interface. It doesn't need to be completely idiot proof. > Will think about this some more and propose some changes to make things > more consistent and flexible (so that pg can be used with and without > oids). I now think this should be cleaned up before 4.0 since making it > clean and consistent will probably require slight changes in behavior > and method signatures which are better done in a major release. How about this? Find all tables with no primary key and add it to self._pkeys with value "oid" and if someone uses get() or update() against one of those tables and there is no OID on it then it will fail. No one should expect those methods to work in that case anyway. The methods will still work if a unique key is supplied anyway. I agree that the time is now for these cleanups but let's try to finish off any API changes by the end of this week. -- D'Arcy J.M. Cain PyGreSQL Development Group http://www.PyGreSQL.org _______________________________________________ PyGreSQL mailing list [email protected] http://mailman.vex.net/mailman/listinfo/pygresql
