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. 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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
