Vik Fearing <v...@postgresfriends.org> writes:
> On 3/2/21 1:02 AM, Dian M Fay wrote:
>> I'd thought that checking v and returning null instead of raising the
>> error would be more friendly, should it be possible to pass an untyped
>> null accidentally instead of on purpose, and I couldn't rule that out.
> As Tom said, that is something that does not belong in this patch.
Yeah, the individual function really doesn't have any way to affect
this, since the error happens on the way to identifying which function
we should call in the first place.
I had the same problem as Dian of the func.sgml hunk winding up in
the wrong place. I think this is practically inevitable unless the
submitter uses more than 3 lines of context for the diff, because
otherwise the context is just boilerplate that looks the same
everywhere in the function tables. Unless the diff is 100% up to date
so that the line numbers are exactly right, patch is likely to guess
wrong about where to insert the new hunk. We'll just have to be
vigilant about that.
I fooled with your test case a bit ... I didn't think it was really
necessary to create and drop a table, when we could just use a VALUES
clause as source of test data. Also you'd forgotten to update the
"descr" description of the function to match the final understanding
of the semantics.
Looks good otherwise, so pushed.
regards, tom lane
