New k-means: Fixed SQL for compensating for dropped centroids

Jira: MADLIB-522

During the reassignment phase k-means may produce stray centroids. In this case
we sample new centroids using kmeans++. The SQL for this operation had a bug,
which is now fixed. Also, for GP, the SQL needed to be written so that it would
not execute on segment nodes.

I added a unit test for the case where a centroid is dropped (this is easy to
reproduce by simply giving an initial centroid more than once).
k-means random seeding: Fixed query execution problems on PG/GP

Jira: MADLIB-522

The previous query for random seeding gave non-deterministic results (sometimes
0 rows were returned, sometime more). Converting a join to a subquery now
guarantees that the query is executed correctly.
Build System: Replace GREENPLUM macro, take 3

Jira: MADLIB-666

Some files were missing the necessary m4_include.
Utilities: Fix for exec_sql_using(), no longer returns invalid memory

Jira: MADLIB-676

It turns out that the function internal_execute_using_kmeans_args(), which is 
internally implemented by the C function exec_sql_using(), calls the function
datumCopy() to copy the result datum from an SPI query. However, this is done
inside SPI_connect() and SPI_finish(), i.e., in a memory context that will be
destroyed by SPI_finish(). Debug builds of Greenplum intentionally overwrite
deallocated memory, which makes the problem reproducible. The overwritten memory
then caused the datum to have invalid header information, which then causes
subsequent usage of that datum to exhibit undefined behavior.

The solution is to copy the result datum into the "upper executor context", e.g.,
with the function SPI_copytuple().
New k-means: Query tuning

Jira: MADLIB-678

During development I added an "OFFSET 0" to the main k-means query, which improved
PostgreSQL performance by a factor of 3, because it caused a GroupAggregate to be
replaced by a HashAggregate. On Greenplum, however, the OFFSET 0 hurts performance.
Therefore, the OFFSET 0 is now only added conditionally. In the future, it would
be nice to completely get rid of this implicit hint to the planner.
Documentation: Replaced inefficient example of using linear regression

Jira: MADLIB-664

The documentation for linear regression included the following example:
SELECT (linregr(price, array[1, bedroom, bath, size])).* FROM houses;
However both Postgres and GPDB have issues where they will expand the .* out and
end up calling the linregr() aggregate more times than is needed.
Madpack: Remove MADlibSchema variable

Jira: MADLIB-645
Sampling: Include macros in SQL file

Jira: MADLIB-678, MADLIB-584

File sample.sql_in did not include the file containing our predefined macros.
This implied that on Greenplum, the weighted sampling aggregate was defined
without a merge function. This severely impacted performance on multi-node
Greenplum instances.
New k-means: Query tuning

Jira: MADLIB-678

The previous optimization fence "OFFSET 0" was suitable for PostgreSQL only. 
However, an optimization fence is also needed on Greenplum -- with it the innermost
subquery can be sped up by a factor around 2.

An alternative would be moving the innermost subquery that contains the
closest_column calls into a common table expression, but unfortunately that is not
supported by earlier Greenplum versions.

It is unfortunate that we have to use such tricks, but we do not want to forgo a
factor-2 performance improvement.
Multi-logistic: Remove indication of cg/igd

Jira: MADLIB-668
SVM: Fix regression when there is no data on segments

Jira: MADLIB-677

In parallel mode, we build one sub-model for each segment.  In the combination
step, we should skip the segments with no source data.

Although it is questionable to use segment id as a logical unit of calculation,
we'll address it as a separate issue in the future.
Function for retrieving column of a matrix

Jira: MADLIB-682

The following query returns NULL in PostgreSQL:
SELECT matrix[1] FROM (SELECT ARRAY[ARRAY[1,2], ARRAY[3,4]] matrix) q;

Reason: Since PostgreSQL does not attach dimensionality to the array type 
information, it is unknown during parsing whether matrix[1] is an expression of
type INTEGER or INTEGER[]. We still want to be able to retrieve columns (or rows)
from matrices. I therefore added a function that handles this special case.
New k-means: Simplified silhouette function

Jira: MADLIB-681

Implemented a function to compute the simplified silhouette coefficient.
Additions for this functions in other parts of the code:

Matrix operations:
- Function that returns the two closest columns in a matrix (relative to a given
  vector).

C++ AL:
- Support for INTEGER arrays
Fixed oversight in previous commit that was mistakenly pushed to master

Jira: None

C++ code for distNorm1 called the wrong internal function. Unit test for
closest_columns function used SQL that Greenplum does not support.
Install create_table_as() workaround also on PostgreSQL

Jira: MADLIB-691

It is convenient to have a uniform interface for CREATE TABLE ... AS, e.g.,
when writing test cases that should run unmodified on all supported
platforms. Obviously, we then can rely on nothing more than the least common
denominator – which is that CTAS is defunct, and our SELECT create_table_as()
workaround has to be used.

In other words, the compatibility module should also be installed for the
PostgreSQL port.
Fixed flawed unit test for compatibility.sql_in

Jira: None

The old unit test had a non-zero chance of failing. There is absolutely no reason,
however, that this unit test should be non-deterministic.
Build support for PostgreSQL 9.2

Jira: MADLIB-662

The decision-tree code contained the function table_exists(), which calls
RangeVarGetRelid(), which used to be a two-parameter function, but is now a
three-paremter macro.
Revert commit 72b11c1 and provide a more suitable fix for MADLIB-637

Jira: MADLIB-637

The fix in commit 72b11c1 moved logic (i.e., the check whether the number of rows
in a state is 0) back to a place where it not supposed to be (linear.cpp).

I added a unit test that ensures the merge function behaves correctly when there are
no rows on one segment, i.e., when the merge function is called with the aggregate's
initial state in one of its arguments.
Multinomial logistic regression: Removed implicit conversion to FLOAT8

Jira: MADLIB-670

There is no reason that multinomial logistic regression should work with all
data set where the dependent variable could be cast to INTEGER. After all, this
implicit conversion could potentially cause unintended behavior for categorical
variables. For instance, different DOUBLE PRECISION values would be mapped to
the same category.

This conversion was a left-over from copied binary logistic-regression code,
where implicit conversion was to BOOLEAN. For binary logistic regression, the
benefits of implicit conversion outweighed the danger of misinterpretation
(which should be rather low for binary variables).

Other change:
- Moved an error message to a more appropriate location.
Fix compilation warning introduced with commit 845210b

Jira: MADLIB-662

Since RangeVarGetRelid() became a macro in PG9.2, embedding a preprocessor directive
within arguments should be avoided, as it is not portable.