Andy Fan <zhihui.fan1213@gmail.com> writes: >> If you use explicit cast, then the code should not be hard, in the >> rewrite stage all information should be known.
> Can you point to me where the code is for the XML stuff?
I think Pavel means XMLTABLE, which IMO is an ugly monstrosity of syntax --- but count on the SQL committee to do it that way :-(.
Thanks for this input!
As far as the current discussion goes, I'm strongly against introducing new functions or operators to do the same things that we already have perfectly good syntax for. "There's more than one way to do it" isn't necessarily a virtue, and for sure it isn't a virtue if people have to rewrite their existing queries to make use of your optimization.
I agree, this is always the best/only reason I'd like to accept.
I do like the idea of attaching a Simplify planner support function to jsonb_numeric (and any other ones that seem worth optimizing)
I have a study planner support function today, that looks great and
I don't think we need much work to do to get our goal, that's amzing.
For all the people who are interested in this topic, I will post a
planner support function soon, you can check that then.
