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
For example dbaccess::OSingleSelectQueryComposer::appendOrderByColumn expects it
(via impl_getColumnName_throw via getTableAlias)
There is some vagueness:
Should the TableName property contain just the table name,
or the *composed* table name
(that is with catalog and/or schema if used by this DB)?
In the case of a query, should it contain the table name (alias)
*in* *the* *query* or of the original table?
In the former case, what meaning do SchemaName and CatalogName have?
They should be empty?
For now, commit as such and deal with the fallout, if any,
when it hits the fan.
If we really need to store these *different* values,
(that is, some code validly needs them)
it would be easier / cleaner / ...
to define *different* properties
for these *different* notions.
Change-Id: I032e619a60e7563cd51478db16cb5e0e5452bfde
The implementation of the LocaleData implements the optional XLocaleData4,
so rather than creating a new interface for the new-style service, we simply
make the service implement XLocaleData4, which in turn implements
XLocaleData3, XLocaleData2, XLocaleData.
Change-Id: I3e9a48b031be6b2aa5e04b376b3940b942add85a
