Re: oid's and primary keys on insert
От | Nigel J. Andrews |
---|---|
Тема | Re: oid's and primary keys on insert |
Дата | |
Msg-id | Pine.LNX.4.21.0208092157240.3235-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: oid's and primary keys on insert ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Ответы |
Re: oid's and primary keys on insert
|
Список | pgsql-general |
On Fri, 9 Aug 2002, Nigel J. Andrews wrote: > > And in a separate message you ask how will PostgreSQL identify data if OIDs are > removed from the system? Well doesn't the data identify the data? It's sad to reply to one's own message but... Ah, I see, you don't know the data in order to find the data. I'm not entirely sure how you get in that situation but I'm sure you do. :) I'm equally not sure how you would get out of without knowing the data. The call to a function to combine two data values to make a unique value would seem to me to require that you know the data. However, I would wary of using the return information from an insert unless I knew with certainty that there was only one row of data being inserted and perhaps more especially unless I knew with certainty that there are no and are never going to be rules defined on inserts to a table. Obviously if you control both database and application then you can be more certain about rules but if not consider the situation where the DB design changes and the table you are currently inserting to becomes a view. In that situation you need to run maintenance on your application because of the DB change and more importantly you'd find that if you can't rewrite the insert procedure to write to the tables (for some reason) then you've got no access to such information as the OID of an inserted row. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
В списке pgsql-general по дате отправления: