Re: Anyone see a need for BTItem/HashItem?

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!

In response to

Browse pgsql-hackers by date

  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