Teodor Sigaev <[email protected]> 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 one in create index command")));
I'd be inclined to keep it but reduce it to level DEBUG1 or so.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
