There are actually two different problems with the example query:

1. The predicate is being applied between two geometries of differing SRIDs.
2. ST_CONTAINS is not supported on a round-earth SRS (SRID 4326 in this case)

The first problem arises because a.location has SRID=4326 (as evidenced by the error message), but the ST_POINT in the query has SRID=0 (default because no SRID was specified in the constructor). To fix it you need to specify the SRID in the ST_POINT constructor. See documentation page http://dcx.sybase.com/index.html#1201/en/dbspatial/pg-api-spatial-st-point-constructor.html for ST_POINT constructor templates.

The second problem is what you asked about: ST_CONTAINS is not supported on SRID 4326. To see a list of which methods are [not] supported under round-earth reference systems, see the following documentation pages: http://dcx.sybase.com/index.html#1201/en/dbspatial/list-of-spatial-methods.html or http://dcx.sybase.com/index.html#1201/en/dbspatial/list-of-spatial-predicates.html (for predicates only).

The precise reason why certain methods are not currently supported under round-earth has to do with implementation-specific details, but the problem is roughly that the strategy we currently use for indexing round-earth data does not distinguish a geometry's boundary from its interior (which is why we don't currently support ST_BOUNDARY under round-earth).

The definition of ST_Contains is as follows (see http://dcx.sybase.com/index.html#1201/en/dbspatial/pg-api-spatial-st-geometry-type-st-contains-method.html ):

The ST_Contains method tests if the geometry-expression completely contains geo2 and there is one or more interior points of geo2 that lies in the interior of the geometry-expression.

See http://dcx.sybase.com/index.html#1201/en/dbspatial/addl-info-stcontains.html for additional explanation.

Under round-earth reference systems the second part of that definition is problematic since it requires distinguishing boundary from interior, which is why it is currently unsupported. However, we do support the (vendor extension) predicate ST_COVERS, which is essentially ST_CONTAINS without the interior intersection requirement. In other words, the only case where ST_CONTAINS and ST_COVERS diverge is when the smaller object occurs entirely on the boundary of the larger object. In this case, ST_CONTAINS returns false, whereas ST_COVERS returns true. The predicates ST_WITHIN and ST_COVEREDBY are analogous.

So, this leaves you two options for your query:

1. Use ST_COVERS/ST_COVEREDBY instead of ST_CONTAINS/ST_WITHIN. Recommended if your application can tolerate the minor change of semantics.
2. Project your round-earth data into a planar SRS before applying the predicate. To improve performance for large tables, you could define the projected geometry as a computed column and then define a spatial index over it.