Crash in ST_Project on NULL input

[realityexists]

Rev 9402. Running

    SELECT ST_Project(NULL, NULL, NULL)

Causes the backend to crash with an access violation/segmentation fault. Happens on both Linux and Windows.

#0  pg_detoast_datum (datum=0x0) at fmgr.c:2233
#1  0x0051d0d6 in geography_project (fcinfo=0x99b76a4) at geography_measurement.c:615
#2  0x081b6cf8 in ExecMakeFunctionResultNoSets (fcache=0x99b7668, econtext=0x9952060, 
    isNull=0xbf8c033f "", isDone=0x0) at execQual.c:1890
...

[pramsey]

Strict

[pramsey]

Can you think of any reason this function shouldn't be defined as strict? the only reason would be to allow a null argument to produce a non-null result… I feel like there's a reason this is not strict… like we return a NULL Azimuth in the case of a zero distance?

[pramsey]

Yes, I remembered. We want to be able to pass in a NULL azimuth, but not necessarily a null anything else. Should be good at r9414.

[realityexists]

Thanks, that fixed it. Yes, a NULL azimuth with a zero distance was the reason it's not strict, though it's a bit unexpected that NULL gets treated as 0 for non-zero distances, eg.

SELECT ST_AsText(ST_Project('POINT(10 10)'::geography, 10000, NULL))

Then again, having it return NULL for non-zero distance, but non-NULL for zero distance might seem strange, too. I don't know what the "right" behaviour would be here.