Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
as opposed to *table* columns,
and notwithstanding HSQLDB 1.8 (our embedded database) bugs.
Actually, supporting ORDER BY on non-select (but table) columns is OPTIONAL for DBMSs
(but quite common)
Change-Id: I6725dfda36b09429a78262bff6f3d3e3dd9032b6
ensures nobody mistakenly modifies it, and makes other code get
a non-empty string where empty string is expected.
Change-Id: I477edd0e589444da19b68381234eb5e85ecd54cc
Undo problematic pollution by sqlbison.hxx
Since with post-2008 (2.4 and later) bison that "#define SQLyylex"\is not active in sqlflex.l, this forces the situation o be the same in all versions of bison, and should notreak anything by itself.
Change-Id: Ie65e3f6cc61dc97adc1d530e3781306ecd176b17
the TABLENAME property contains the *original* tablename, but this column should have the query table alias as table name
Change-Id: Ieeb362f38b701b92998e293dda474bad36e5e577
This fixes parsing failures, like e.g.
warn:legacy.osl:30429:1:dbaccess/source/core/api/SingleSelectQueryComposer.cxx:783: OSingleSelectQueryComposer::getColumns: could not parse the column retrieval statement!
when opening query "Balance" of https://bugs.freedesktop.org/attachment.cgi?id=71964
OTOH, since we have reduce/reduce conflicts, we might have true
ambiguities in our grammar. This change makes the parsing fail
in the presence of full-expression ambiguities instead of making
a ~arbitrary choice.
Change-Id: I88574da91045dd52f198f193c78d144302f298a4
When converting a parse tree to SQL snippet for a predicate in the
context of a column, we skip the name of the same column in 'simple'
cases.
This is used mainly in the "Criterion" lines of query design,
and in the search/filter dialogs of forms, tables, etc.
In all other cases (such as when creating a full SQL command, or for
references to *other* columns than the context one), the column name
must be printed out.
In this respect, the condition "should we skip the column name?" in
impl_parseLikeNodeToString_throw was buggy, and different from the
one in the general case (in impl_parseNodeToString_throw), leading
to generating invalid SQL like:
SELECT foo, bar FROM baz LEFT JOIN qux ON LIKE qux.quu
instead of
SELECT foo, bar FROM baz LEFT JOIN qux ON baz.baa LIKE qux.quu
Change-Id: Ie14fce319554a66feb0fd0ce1a03d947a46a820a
This reverts commit 10777b37536be16c6d2e167b59e9e31e37ba3517.
The problem has been fixed in a more safe way by making columnMatchP
treat the case where rParam.xField is not set instead of requiring
it from all callers.
Change-Id: Ic68a764e08446a7b669c6030c2bcd55c7d31772b
