Martijn van Oosterhout writes:
> On Mon, Jan 16, 2006 at 12:07:44PM -0500, Tom Lane wrote:
>> Since you didn't understand what I was saying, I suspect that plan A is
>> too confusing ...
> Umm, yeah. Now you've explained it I think it should be excluded on the
> basis that it'll be a source of bu
On Mon, Jan 16, 2006 at 12:07:44PM -0500, Tom Lane wrote:
> Since you didn't understand what I was saying, I suspect that plan A is
> too confusing ...
Umm, yeah. Now you've explained it I think it should be excluded on the
basis that it'll be a source of bugs. For all the places that matter a
row
Martijn van Oosterhout writes:
> ISTM that row-wise comparisons, as far as indexes are concerned are
> actually simpler than normal scan-keys. For example, if you have the
> condition (a,b) >= (5,1) then once the index has found that point,
> every subsequent entry in the index matches (except pos
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sun, 2006-01-15 at 18:03 -0500, Tom Lane wrote:
>> There's one nontrivial decision still to make about how to implement
>> proper per-spec row-comparison operations, namely: how a row
>> comparison ought to be represented in the index access method API.
On Sun, Jan 15, 2006 at 06:03:12PM -0500, Tom Lane wrote:
> There's one nontrivial decision still to make about how to implement
> proper per-spec row-comparison operations, namely: how a row
> comparison ought to be represented in the index access method API.
> The current representation of index
There's one nontrivial decision still to make about how to implement
proper per-spec row-comparison operations, namely: how a row
comparison ought to be represented in the index access method API.
The current representation of index conditions in the AM API is an
array of ScanKey structs, one per "
