| From: | Antti Haapala <antti(dot)haapala(at)iki(dot)fi> |
|---|---|
| To: | Curt Sampson <cjs(at)cynic(dot)net> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Call for objections: put back OIDs in CREATE TABLE |
| Date: | 2003-01-27 07:49:17 |
| Message-ID: | Pine.GSO.4.44.0301270923460.6710-100000@paju.oulu.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Al Sutton | 2003-01-27 07:59:18 | Re: [mail] Re: Windows Build System |
| Previous Message | Bradley Baetz | 2003-01-27 07:29:19 | Re: [BUGS] New hashed IN code ignores distinctiveness of subquery |