> > a) effectiveness. The ending performance should be similar like your > current patch, but without necessity to use planner support API. >
So the cost is we need to create a new & different framework. > > b) because you can write only var := j->'f', and plpgsql forces cast > function execution, but not via planner. > var a := 1 needs going with planner, IIUC, same with j->'f'. c) nothing else. It should not to require to modify cast function > definitions > If you look at how the planner support function works, that is pretty simple, just modify the prosupport attribute. I'm not sure this should be called an issue or avoiding it can be described as a benefit. I don't think the current case is as bad as the other ones like users needing to modify their queries or type-safety system being broken. So personally I'm not willing to creating some thing new & heavy. However I'm open to see what others say. -- Best Regards Andy Fan
