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.
a) effectiveness. The ending performance should be similar like your current patch, but without necessity to use planner support API.
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'.
b) because you can write only var := j->'f', and plpgsql forces cast function execution, but not via planner.
c) nothing else. It should not to require to modify cast function definitions If you look at how the planner support function works, that ispretty simple, just modify the prosupport attribute. I'm not surethis should be called an issue or avoiding it can be describedas a benefit. I don't think the current case is as bad as the other ones likeusers needing to modify their queries or type-safety systembeing broken. So personally I'm not willing to creating something new & heavy. However I'm open to see what others say.
c) nothing else. It should not to require to modify cast function definitions
-- Best RegardsAndy Fan
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных
