From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Markus Wanner" <markus(at)bluegap(dot)ch> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: setting up scan keys |
Date: | 2009-08-25 13:33:15 |
Message-ID: | 19973.1251207195@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Markus Wanner" <markus(at)bluegap(dot)ch> writes:
> Up until now I've used something along the following lines to setup
> the scan keys for a BTGreaterStrategy scan:
> procinfo = index_getprocinfo(index_rel, i + 1, BTORDER_PROC);
> ScanKeyEntryInitializeWithInfo(&skeys[i],
> SK_ROW_MEMBER,
> (AttrNumber) (i + 1),
> strategy,
> InvalidOid,
> procinfo,
> value);
Either the SK_ROW_MEMBER flag is entirely wrong, or this is part of
a larger structure that you're not telling us about. But also,
from anywhere outside the btree index AM itself you should not be
dealing in the support function. The scankey is supposed to refer
to an operator's underlying function. Your second try looks a bit
saner, but it's still using SK_ROW_MEMBER ... why?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Werner Echezuria | 2009-08-25 13:47:55 | return HeapTuple |
Previous Message | Robert Haas | 2009-08-25 13:24:14 | Re: DELETE syntax on JOINS |