| From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alessio Bragadini" <alessio(at)albourne(dot)com> |
| Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: Re: postgres TODO |
| Date: | 2000-07-12 01:55:42 |
| Message-ID: | 001f01bfeba4$497791c0$2801007e@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Tom Lane
>
> it. We already return the OID which is sufficient info to select the
> row again if you need it. Returning the primary key would be
> considerably more work for no visible gain in functionality...
>
Is OID really sufficient ?
I've wondered why people love OID so much.
PostgreSQL provides no specific access method using OID.
We couldn't assume that every table has its OID index,
when we need to handle general resultsets.
In fact,I've never created OID indexes on user tables.
I've forgotten to propose that INSERT returns TID together
with OID before 7.0. This has been in my mind since
I planned to implement Tid scan. Different from OID
,TID has its specific (fast) access method now.
Comments ?
Regards.
Hiroshi Inoue
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-07-12 02:06:54 | Re: Vacuum only with 20% old tuples |
| Previous Message | Alfred Perlstein | 2000-07-12 01:53:18 | Connection pooling. |