RE: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, October 12, 1999 4:08 AM
> To: Hiroshi Inoue
> Cc: Bruce Momjian; pgsql-hackers
> Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
> operator) 
> 
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > Yes,I have done a part of my story.
> > I would add new type of path and scan by which we are able to access
> > tids directly.
> 
> Yes, new path type, new plan type, probably a new access method if
> you want to keep things clean in the executor, cost-estimation routines
> in the planner, etc. etc.
> 
> Looks like a lot of work, and a lot of added code bulk that will
> have to be maintained.

You are right and It's the reason I have announced this issue
many times. 

>  I haven't figured out why you think it's
> worth it... tids are so transient that I don't see much need for
> finding tuples by them...
>

As far as I know,many DBMSs have means to access tuples
directly.
I have been wondering why PostgreSQL doesn't support such
means.

PostgreSQL isn't perfect and this kind of means are necessary
to make up for the deficiency,I think. 
For example how do we implement advanced features of ODBC
/JDBC drivers etc without this kind of support ?  

OIDs are preferable for such means because they are
invariant. But unfortunately OIDs have no guarantee that
have indexes and even with indexes it isn't the fastest way.

TIDs are transient,so I have provided built-in functions 
currtid() to follow update chain of links.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp