Jeff Davis <[EMAIL PROTECTED]> writes:
> I attached a proposed documentation patch. I wasn't able to readily see
> the implications of writing a function in SQL regarding an index, so
> perhaps this will help someone in the future (not that many people will
> attempt writing index access methods in
On Wed, 2005-01-12 at 18:12 -0500, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I'm wondering if the function under = is an SQL function being inlined.
>
> Bingo --- that's surely it. After inlining, the expression would no
> longer look like it matched the index.
>
> You don'
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I'm wondering if the function under = is an SQL function being inlined.
Bingo --- that's surely it. After inlining, the expression would no
longer look like it matched the index.
You don't want to use SQL functions to define indexable operators
anyway.
On Wed, 12 Jan 2005, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I think I created a type that was compatible with the btree index, and
> > everything seems fine, except that it doesn't actually use the index. I
> > created the operators and the opclass as well.
>
> > => explain s
On Wed, Jan 12, 2005 at 04:43:13PM -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> >
> > => explain select * from test where t = '(2)';
> > QUERY PLAN
> > -
> > Seq Scan on test (cos
Jeff Davis <[EMAIL PROTECTED]> writes:
> I think I created a type that was compatible with the btree index, and
> everything seems fine, except that it doesn't actually use the index. I
> created the operators and the opclass as well.
> => explain select * from test where t = '(2)';
>
I think I created a type that was compatible with the btree index, and
everything seems fine, except that it doesn't actually use the index. I
created the operators and the opclass as well.
=> create type type2 as (i int);
=> create operator = (leftarg=type2,rightarg=type2,procedure=type2_eq);
=>
