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
Problem caused by commit:
16c9ce4877def18ca4578171a96615a632d08092
This commit contains code deduplication.
The deduplication removed one needed check (rParam.xFiled.is()),
which causes segfault when member function of rParam.xField
is called inside columnMatchP().
Change-Id: Ibbdaa758dbbce4b76094e6cc120022ef276b30c4
lets try this hack, if it fails revert and I'll just
manually update the baseline with a newer flex than
flex-2.5.4a-41.fc6
Change-Id: If644489e80fc4e4cdba97808af0fe4d544d08646
nCount == 5 is impossible; the grammar has changed since this code was written.
It used to refer to case '(' joined_table ')' range_variable op_column_commalist
which has become just '(' joined_table ')'
which thus has (by definition) no table range (alias).
Case changed in mega-(merge-)commit:
commit c41efc6d0b2740be4243fd696385f8dbcec0aefe
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Wed Nov 19 17:43:08 2008 +0000
CWS-TOOLING: integrate CWS dba301a_DEV300
which seems to have done the other necessary adaptations to this code
and elsewhere.
Change-Id: I96ddbefbf34d6c155435b78aa9e5037a760232ed
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
...replacing hard-coded GCC version checks. Those checks that guard
#pragma GCC diagnostic ignored "-Wnon-virtual-dtor"
appear relevant only for GCC itself, not Clang (which used to fail the old
guards because it typically announces itself with a rather low
__GNUC__/__GNUC_MINOR__ version), see 6e67c03dc0225fc66343546b14e902b9d238b1a3
"Enable -Wnon-virtual-dtor for GCC 4.6"
Change-Id: I6bfa4d5caa6192e7a203ce829682bf6bb8d61a1b
This reverts commit b659d7c33fcacdbbef86557e78f071abf94bead2.
That commit appears to have broken the build on Linux. Reverting it
fixes it.
Change-Id: I70d62c04e9fb284ed2c360c0976d0cbeafc2ddc2
Meaning, these two functions have the same behaviour,
they produce the same output (and side-effects)
when called on the same input.
traverseORCriteria handles only the actual "foo OR bar" case,
and hands off all other cases to traverseANDCriteria.
But, lo and behold, traverseANDCriteria also handles
the "foo OR bar" case, in the same manner!
Change-Id: I10410e88ce48852b60d1d688fe2865923de9d80b
