Re: Re: Thought on OIDs
От | Rod Taylor |
---|---|
Тема | Re: Re: Thought on OIDs |
Дата | |
Msg-id | 028401c0a349$37bd5930$6500000a@jester обсуждение исходный текст |
Ответ на | Re: Re: Thought on OIDs (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-general |
I use XID's regularly now for historical purposes (delayed reversion of entire operations -- handled by an interface of course where appropriate) but OID's I could certainly live without. However, PHP currently returns the OID in from pg_getlastoid() which I use to select from the table the last PRIMARY KEY entry. Getting this key before sometimes isn't an option (triggers handle them sometimes). If I could have a pg_getlastprimarykey() function which returns a hash of name / value pairs of the new key without using the OID it would be ideal. -- Rod Taylor There are always four sides to every story: your side, their side, the truth, and what really happened. ----- Original Message ----- From: "Peter Eisentraut" <peter_e@gmx.net> To: "Rod Taylor" <rod.taylor@inquent.com> Cc: <pgsql-general@postgresql.org> Sent: Friday, March 02, 2001 11:31 AM Subject: Re: [GENERAL] Re: Thought on OIDs > Rod Taylor writes: > > > Someones bound to hit it in a year or 2 as Postgres is getting pretty > > good for large projects as well as the small, especially with 7.1's > > speed enhancements. Hopefully 7.2 will create cycling OIDs and XIDs. > > Then less problems in 'unlimited' extendability. > > The easiest approach for OIDs will probably be making them optional in the > first place. For the vast majority of users, the OIDs are just wasting > space. > > The cycling XID idea is based on the assertion that eventually all > transactions will be closed, at which time a record is either known > committed or known dead so that the XID can be recycled. For OIDs, this > is not practical. And if you wanted OIDs that automatically fill in the > holes, that's probably not realistic. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
В списке pgsql-general по дате отправления: