2016-09-12 8:14 GMT+02:00 Craig Ringer <cr...@2ndquadrant.com>: > On 12 September 2016 at 14:02, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > Hi > > > > There is some opened questions - the standard (and some other databases) > > requires entering XPath expression as string literal. > > > > I am thinking so it is too strong not necessary limit - (it enforces > dynamic > > query in more cases), so I allowed the expressions there. > > I agree. There's no reason not to permit expressions there, and there > are many other places where we have similar extensions. > > > Another questions is when these expressions should be evaluated. There > are > > two possibilities - once per query, once per input row. I selected "once > per > > input row mode" - it is simpler to implement it, and it is consistent > with > > other "similar" generators - see the behave and related discussion to > > "array_to_string" and evaluation of separator argument. The switch to > "once > > per query" should not be hard - but it can be strange for users, because > > some his volatile expression should be stable. > > I would've expected once per query. There's no way the expressions can > reference the row data, so there's no reason to evaluate them each > time. >
I disagree - it is hypothetical situation but it is possible if somebody store documents like id, xml ===== id = 1, xml = <doc id = 1> ....<> id = 2, xml = <doc id = 2> .... Then evaluating one per query doesn't allow to use any reference to other columns, and doesn't to build expressions like PATH (...[@id= ' || id || '] My opinion is not too strong - now, what I know, there is not any only once per query executed expression in Postgres - so this implementation will be a precedent. > > The only use case I see for evaluating them each time is - maybe - > DEFAULT. Where maybe there's a use for nextval() or other volatile > functions. But honestly, I think that's better done explicitly in a > post-pass, i.e. > > select uuid_generate_v4(), x.* > from ( > xmltable(.....) x > ); > > in cases where that's what the user actually wants. > DEFAULT should be evaluated per output row - anybody can use volatile function there - example: when I have not data - use some random there Regards Pavel > > There's no other case I can think of where expressions as arguments to > set-returning functions are evaluated once per output row. > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
