> > Accordingly, I think the paragraph beginning "Unlike regular PostgreSQL > functions," is more likely to perplex readers than to enlighten them. > What it says about column_expression does not seem to lead to any useful > difference from the behavior if it were "just like regular PostgreSQL > functions". >
regular Postgres' functions has evaluated all arguments before own execution. I think so this note is related much more to expressions used as defaults. > The part about usefully using volatile functions in default_expression > remains important to mention. > > The statement in an earlier paragraph that "It is possible for a > default_expression to reference the value of output columns that appear > prior to it in the column list" still may need some rework, because it > does not seem possible to refer to prior columns /within xmltable's own > column list/ (though that could be useful, and I think it is intended > in the standard). Doesn't seem to work in Oracle either.... > > While it does seem possible to refer to columns supplied by > /earlier FROM items in the containing SELECT/, that simply results in > multiple calls of xmltable, just as in the column_expression case. > > >> I think the same example would produce the same output even with feature > >> (2) > >> absent. It's LATERAL doing the magic there. So I am doubtful that it > >> demonstrates (2). > > > > LATERAL is necessary, because XMLTABLE can be used only in FROM clause, > > and in this case XMLTABLE has mutable parameters. > > For what it's worth, if I repeat the query with the word LATERAL removed, > it works just the same. I think that's simply because the LATERAL behavior > is implied for a function-call FROM item, so the explicit word isn't > needed. > The main thing is, evaluation proceeds in the way described under LATERAL > in the ref page for SELECT. > In this case the LATERAL keyword is optional - with or without this keyword it is lateral join. Regards Pavel > > Regards, > -Chap >
