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.
