Re: Using oids
От | Bo Lorentsen |
---|---|
Тема | Re: Using oids |
Дата | |
Msg-id | 1062584442.7853.64.camel@localhost обсуждение исходный текст |
Ответ на | Re: Using oids ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>) |
Ответы |
Re: Using oids
|
Список | pgsql-general |
On Wed, 2003-09-03 at 11:38, Shridhar Daithankar wrote: > Well, what I do is, declare a serate sequence, retrive next available value and > explicitly insert it into a integer field. That avoids having to retrieve the > latest value again. Yeps, this is what I call an application specific implimentation, as one can't do this at a more genral layer (that does not know about your table layout). Like having a general function that insert a row and return the newly inserted row, containing the defaults set by PG. My code contain this function (http://www.lue.dk/prj/dbc), and I have no way to make this work if I'm not able to fetch the oid after an insert, in some way. > I don't know if this is a widespread practice but I find it useful for more > than one way in the environment in which I program. You are not the only one recommenting this solution :-) > I understand. With growing use of 64 bit hardware, 4 billion will be history > pretty soon. Agreed ! > However historically oids were assumed to be 32 bit. There could be places > which unintentionally assumed it as such. Cleaning all those places is pretty > difficult given the big code base postgresql has. One day I will try to look after myself, but what does PG do internaly, when referring to rows in a unique way (lets say in an index) ? > If you compile postgresql with Oid as 64 bit integer, that will work in most > cases probably. However it does not guarantee that it will always work. There > always could be some places which assumed 32 bit data types. But if convertet to a string type, all involved places would fail, and no uncertency are involved when fixing it (well, a little too primitive argument, I know) :-) > You can request this to be a TODO to hackers. They will decide if this is worth > having it. Personally I support it the way it is. Optionally available. I'm not sure, if my skills reach this fare, but thanks for the advice. And for the rest --- we disagree :-) > For large table containing billions of rows, Oids add to tuple size and overall > IO. If you are not using Oids, they become overhead. Ability to turn them off > is certainly nice.. Yeps, if they really are not nessesary. /B
В списке pgsql-general по дате отправления: