Research indicates that this problem is caused by having an incorrect proj4 string in the proj4text field of the spatial_ref_sys table. I didn't think this was possible, because I got the PostGIS insert statement for this projection (6856) directly from spatialreference.org. But as you can see from the insert text, spatialreference.org provides srtext, but not proj4text. Updating the table with the correct proj4text should solve the problem.
And in the future, I shall be more watchful of the information I get from spatialreference.org.
http://spatialreference.org/ref/sr-org/6856/postgis/
From postgis docs
, ST_Buffer calculations are performed in the units of the SRID. In this case, you are using a buffer of 2500 degrees, so yeah... that covers any ST_Contains. Which also speaks to your question of importance of setting an SRID. It is important, and in your case you probably need a projected coordinate system such as UTM.
As to efficiency, and whether or not you even need to segment your circles (the last argument in ST_Buffer), that depends on how the GEOS library performs those calculations. I don't have any insight on that, and even if I did, you probably will just want to test segments vs. circles on a heap of points and measure the results.
In response to the question below, use ST_Transform after ST_SetSRID and before ST_Buffer to work in proper units. This will require you to also set and transform SRID of the comparison point. Here's an example that returns one point contained, and one point not:
SELECT
ST_Contains(
ST_Buffer(ST_Transform(ST_SetSRID(ST_MakePoint(39.6346, 2.6308), 4326), 32632), 2500),
ST_Transform(ST_SetSRID(ST_MakePoint(39.6300, 2.6300), 4326), 32632)
) point1_is_in_buffer,
ST_Contains(
ST_Buffer(ST_Transform(ST_SetSRID(ST_MakePoint(39.6346, 2.6308), 4326), 32632), 2500),
ST_Transform(ST_SetSRID(ST_MakePoint(39.0000, 2.0000), 4326), 32632)
) point2_is_in_buffer;
Note that if you choose to store your Geometry in the projected coordinate system, you will be able to take advantage of spatial indexes using Gist. This can potentially reduce queries by orders of magnitude, especially on big cross joins.
Best Answer
Your input geometry needs to be built from the existing geometry.
If I want to just change the Y coordinate (i.e. Latitude) to 66.23, I can use the following command (when data is of type geometry):
Since your data is in Geography type, you can use a SQL command like this: