Re: Implementing JDBC3 methods (Was: JDBC and fetching
От | Dave Cramer |
---|---|
Тема | Re: Implementing JDBC3 methods (Was: JDBC and fetching |
Дата | |
Msg-id | 1032427502.26943.110.camel@inspiron.cramers обсуждение исходный текст |
Ответ на | JDBC API Tests (Al Sutton <al@alsutton.com>) |
Ответы |
Re: Implementing JDBC3 methods (Was: JDBC and fetching
|
Список | pgsql-jdbc |
On Thu, 2002-09-19 at 04:17, Michael Stephenson wrote: > Dave wrote: > >>I think so. I just read over the JDBC specification. It is not very > >>specific, about what is considered a generated key. I suppose it would be > >>any unique key (or field value?) that is automatically generated by the data > >>source / database. In postgresql, this could be a SERIAL, a field with a > >>default value from a SEQUENCE, of even an OID. This *could* also be a value > >>supplied by a user-defined trigger, depends on the point of view. > > > > I would think it would have to be a sequence, and an index This should > > be possible to find out through a select. > > ie find if the table has a default on an index column which selects > > nextval. > > That isn't really sufficient. There doesn't seem to be anything to stop you > inserting an explicit value into a column which is of type serial, so you need > to know whether the sequence was actually used or not. Trying to find that the > obvious way you hit the problem that a sequence might have been used earlier in > this transaction in a different statement (or even elsewhere in this statement).. That's the only way, and will have to do. One thing to realize is that once a sequence has been used, it can't be rolled back, so it is unique. > > Michael > > -- > Web Applications Developer > Open World Ltd, 11 Riverside Court, Riverside Road, Bath, BA2 3DZ. > Tel: +44 1225 444950 Fax: +44 1225 336738 http://www.openworld.co.uk/ > > CONFIDENTIALITY NOTICE > The information contained in this message is confidential, intended only for > the use of the individual or the entity named as recipient. If the reader of > this message is not that recipient, you are notified that any dissemination, > distribution or copy of this message is strictly prohibited. If you have > received this message in error, please immediately notify us by telephone on > the number above. Your co-operation is appreciated. > >
В списке pgsql-jdbc по дате отправления: