Teodor Sigaev <teodor@sigaev.ru> writes:
>> I don't like throwing an error there; I wish there were a way for the
>> generic code to apply the fallbackSplit code instead. I see that
>> in this particular formulation it's dependent on the datatype ---
>> can we get around that, by having it invoke the union method?
> Done. rtree.patch.gz contains patch for gistproc.c, genericsplit.patch.gz adds
> simple genericPickSplit to gistsplit.c to workaround bug of user-defined picksplit.
This looks good to me. I tested it to the extent of verifying that
either patch individually would prevent the originally-reported failure.
The only question I have is whether we want this nag message or not:
! ereport(LOG,
! (errcode(ERRCODE_INTERNAL_ERROR),
! errmsg("Picksplit method for %d column of index \"%s\" failed",
! attno+1, RelationGetRelationName(r)),
! errhint("Index is not optimal, to optimize it contact developer or try to use the column as a second
onein create index command")));
I'd be inclined to keep it but reduce it to level DEBUG1 or so.
regards, tom lane
