The SQL parser (for no good reason?) in a few places accepts only a very restricted notion of literal where an arbitrary expression should be allowed. The most prominent place is in a column's value definition in a SELECT statement (where one usually has a column name reference to a table in the FROM clause). Don't forget to adapt OQueryDesignView::fillFunctionInfo in dbaccess/source/ui/querydesign/QueryDesignView.cxx.
Interesting parse nodes: boolean_primary, value_exp_primary, num_primary, datetime_primary, char_primary, bit_primary and related.
Also look at what is accepted within a subclause of a WHERE clause, e.g. as left/right handsides of operators such as equality; that should be a good start for a general notion of "expression".
(In reply to comment #0) > The SQL parser (for no good reason?) in a few places accepts only a very restricted notion of literal where an arbitrary expression should be allowed. > The most prominent place is in a column's value definition in a SELECT statement (where one usually has a column name reference to a table in the FROM clause). But also e.g. in arguments to many functions, such as BIT_LENGTH, etc.
Adding self to CC if not already on
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.