Re: Call for objections: put back OIDs in CREATE TABLE - Mailing list pgsql-hackers

From Antti Haapala
Subject Re: Call for objections: put back OIDs in CREATE TABLE
Date
Msg-id Pine.GSO.4.44.0301270923460.6710-100000@paju.oulu.fi
Whole thread Raw
In response to Re: Call for objections: put back OIDs in CREATE TABLE  (Curt Sampson <cjs@cynic.net>)
Responses Re: Call for objections: put back OIDs in CREATE TABLE
List 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 by date:

Previous
From: Bradley Baetz
Date:
Subject: Re: [BUGS] New hashed IN code ignores distinctiveness of subquery
Next
From: "Al Sutton"
Date:
Subject: Re: [mail] Re: Windows Build System