From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Anyone see a need for BTItem/HashItem? |
Date: | 2006-01-16 21:50:59 |
Message-ID: | 20060116215059.GG14577@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 16, 2006 at 04:21:50PM -0500, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Mon, Jan 16, 2006 at 04:02:07PM -0500, Tom Lane wrote:
> >> David Fetter <david(at)fetter(dot)org> writes:
> >>> If you cut it out, what will the "heap" and "index" access
> >>> methods needed for SQL/MED use?
> >>
> >> What's that have to do with this?
>
> > I'm sure you'll correct me if I'm mistaken, but this is a
> > candidate for the spot where such interfaces--think of Informix's
> > Virtual (Table|Index) Interface--would go.
>
> Can't imagine putting anything related to external-database access
> inside either the btree or hash AMs; it'd only make sense to handle
> it at higher levels. It's barely conceivable that external access
> would make sense as a specialized AM in its own right, but I don't
> see managing external links exclusively within the indexes.
>
> IOW, if we did need extra stuff in IndexTuples for external access,
> we'd want to put it inside IndexTuple, not in a place where it could
> only be seen by these AMs.
Thanks for the explanation :)
Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 415 235 3778
Remember to vote!
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2006-01-16 21:51:15 | Re: source documentation tool doxygen |
Previous Message | Martijn van Oosterhout | 2006-01-16 21:49:43 | Re: ScanKey representation for RowCompare index conditions |