út 15. 8. 2023 v 9:05 odesílatel Andy Fan <zhihui.fan1...@gmail.com> napsal:
> > >> 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. > yes, it can be less work, code than for example introduction of "anycompatible". > >> > 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'. > i was wrong, the planner is full, but the executor is reduced. > > 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. > ok regards Pavel > > -- > Best Regards > Andy Fan >
