Re: Call for objections: put back OIDs in CREATE TABLE
От | Antti Haapala |
---|---|
Тема | Re: Call for objections: put back OIDs in CREATE TABLE |
Дата | |
Msg-id | Pine.GSO.4.44.0301270923460.6710-100000@paju.oulu.fi обсуждение исходный текст |
Ответ на | Re: Call for objections: put back OIDs in CREATE TABLE (Curt Sampson <cjs@cynic.net>) |
Ответы |
Re: Call for objections: put back OIDs in CREATE TABLE
|
Список | pgsql-hackers |
> > Ross, you make some powerful arguments here. Probably the most > > significant was the idea that you need a unique identifier for every > > row, and it should be of a consistent type, which primary key is not. > > I don't see why you need a unqiue identifier per row, nor do I see why, > if you are going to have one, it needs to be the same type across all > tables. If i had table with multi col primary key like... create table devices ( major int4, minor int4, primary key (major, minor)); ... and do this: insert into devices (major, minor values (224, find_free_minor_for(224)) should the database report something like INSERT '{<([\'224\', \'89\'])>}' 1 which I could then parse in my client program and try to recover my fresh brand new primary key from it? No thanks... Anyways, I've got an idea: what about having option that INSERTs return "oid_status" in form major = '224' and minor = '10' or state = 'ca' ? Then you could just throw this expression into a select query after where ;P And tables would never need row oids... -- Antti Haapala
В списке pgsql-hackers по дате отправления: