All,
* Stephen Frost (sfrost@snowman.net) wrote:
> > It seems that the reason for this is to be consistent with
> > BuildIndexValueDescription, which seems to do the same thing to simplify
> > the stuff going on at check_exclusion_constraint() -- by returning an
> > empty string, that code doesn't need to check which of the returned
> > values is empty, only whether both are. That seems an odd choice to me;
> > it seems better to me to be specific, i.e. include each of the %s
> > depending on whether the returned string is null or not. You would have
> > three possible different errdetails, but that seems a good thing anyway.
>
> Right, ExecBuildSlotValueDescription() was made to be consistent with
> BuildIndexValueDescription. The reason for BuildIndexValueDescription
> returning an empty string is different from why you hypothosize though-
> it's exported and I was a bit worried that existing external callers
> might not be prepared for it to return a NULL instead of a string of
> some kind. If this was a green field instead of a back-patch fix, I'd
> certainly return NULL instead.
>
> If others feel that's not a good reason to avoid returning NULL, I can
> certainly change it around.
Does anyone else want to weigh in on this?
It's no guarantee, but checking codesearch.debian.net, the only packages
which include BuildIndexValueDescription are PG core and derivatives.
Thanks!
Stephen