Re: 7.2 fe-exec.c patch to PQescapeString()

Tom Lane wrote:

>
> I agree with Bruce on this one.  I think the right analogy is not
> one of "let's be friendly if he passes a null pointer" but "should
> we try to detect a bogus input pointer".  If we are passed a random
> bit-pattern for the 'from' pointer, we will almost certainly core
> dump on trying to dereference it.  We have no reasonable or portable
> way to defend against that.  I tend to think that being passed a null
> pointer is a member of this class of events, not something that we
> should have a special-case defense against.  It is a caller bug and
> the caller should fix it, just the same as if the caller passed us
> a bogus non-null pointer.


Well, I can see your perspective and it sounds reasonable.  Null ptrs are a
member of the general class called "bogus input pointers."  But the fact that
you *can* detect a null ptr while you *cannot* detect a random bit pattern is
precisely why I think it ought not to be sub-classified in the same
things-we-defend-against category as the random bit pattern.  You *do* have a
reasonable and portable way to defend against null, unlike the random bit
pattern.

Ed