This change removes the whitelisting check on the WHERE clauses. Note that, before
this change, citus was already allowing all types of nodes with the following
format (i.e., wrap with a boolean test):
* SELECT col FROM table WHERE (ANY EXPRESSION) is TRUE;
Thus, this change is mostly useful for allowing the expressions in the WHERE clause
directly and avoiding "unsupport clause type" errors.
This reverts commit 77fa8494dd.
Makefile.global.in already handles PGINCLUDEDIR -- the problem is
incorrect #include statements in some of the sources.
Prior to this change, it was not possible to use UDFs in repartitioned
subqueries. The reason is that we were setting the search path explicitly
and omiting public schema from that path.
This change adds the public schema to the explicitly set search path.
This definition:
causes a compilation failure on platforms where HAVE_LL_CONSTANTS is
defined in pg_config.h. In those cases INT64CONST(4294967296UL) will
expand to 4294967296ULLL. It's not clear to me whether this should be
a signed or an unsigned constant -- I'm guessing you'ld have used
UINT64CONST() if you'ld really wanted an unsigned type. Simply
dropping the 'UL' suffix here correctly produces a constant case to
the desired signed 64bit integer type on both 32- and 64-bit
platforms.
Fixes issue #258
Prior to this change, Citus gives a deceptive NOTICE message when a query
including ANY or ALL on a non-partition column is issued on a hash
partitioned table.
Let the github_events table be hash-distributed on repo_id column. Then,
issuing this query:
SELECT count(*) FROM github_events WHERE event_id = ANY ('{1,2,3}')
Gives this message:
NOTICE: cannot use shard pruning with ANY (array expression)
HINT: Consider rewriting the expression with OR clauses.
Note that since event_id is not the partition column, shard pruning would
not be applied in any case. However, the NOTICE message would be valid
and be given if the ANY clause would have been applied on repo_id column.
Reviewer: Murat Tuncer
WORKER_LENGTH + 1 is too large. Fixing this has no impact on the string
that is ultimately copied, as it's impossible for the source string to
be any larger to begin with.