Re: [HACKERS] Enhanced containment selectivity function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Matteo Beccati <php(at)beccati(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Enhanced containment selectivity function
Date: 2006-04-26 20:33:06
Message-ID: 20963.1146083586@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> OK, reverted, but I saw it using contsel() so I figured we were allowing
> it, but I see contsel() is used by our "box", so ltree was just using
> something that was already there. Let me see if I can break out the new
> selectivity function into /contrib.

What really needs to happen next is to think about which bits of
selfuncs.c should be exposed --- what's generally useful, and do we
think that it has an API clean/stable enough to expose? The reason I
kept all that stuff static so far was because it got whacked around
every release or two, and I didn't want to be constrained by worries
about breaking outside modules. I'd still prefer to minimize the number
of routines exposed, so some thought is needed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Taral 2006-04-26 20:45:00 ANSI-strict pointer aliasing rules
Previous Message Bruce Momjian 2006-04-26 20:26:53 Re: [HACKERS] Enhanced containment selectivity function

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-04-26 20:45:48 Re: [HACKERS] Enhanced containment selectivity function
Previous Message Bruce Momjian 2006-04-26 20:26:53 Re: [HACKERS] Enhanced containment selectivity function