According to their documentation the spatial objects can be of the following
POINT(0 0)
LINESTRING(0 0,1 1,1 2)
POLYGON((0 0,4 0,4 4,0 4,0 0),(1 1, 2 1, 2 2, 1 2,1 1))
MULTIPOINT(0 0,1 2)
MULTILINESTRING((0 0,1 1,1 2),(2 3,3 2,5 4))
MULTIPOLYGON(((0 0,4 0,4 4,0 4,0 0),(1 1,2 1,2 2,1 2,1 1)), ((-1 -1,-1 -2,-2 -2,-2 -1,-1 -1)))
GEOMETRYCOLLECTION(POINT(2 3),LINESTRING(2 3,3 4))
However , there is no circle type, where I can just store a point and its radius. And have the same feature where I can get a bounding box for that circle when do I query if the point exist within it.
There is no Postgis type for representing a circle with 100% accuracy, ie, with a centre point and a radius, as there is with SQL Server's circular arcs. As pointed out in the comments, you can approximate a circle with the 2nd form of ST_Buffer, ie, ST_Buffer(point, distance, num_seg_quarter_circle). As you increase the 3rd parameter, you get closer to an actual circle, at the cost of greater calculation times and storage space.
The return type of buffering a point will be a Polygon, as can be seen from running, something like:
SELECT ST_GeometryType(ST_Buffer(ST_MakePoint(0,0),100));
My personal view is that while allowing for an arc type may improve the precision of calculations involving circles, it also complicates things, as you are no longer dealing with geometric objects composed entirely of points, linestrings and polygons (the latter two, being also composed of points).
You can always run tests increasing the 3rd parameter of ST_Buffer, until you get a result that is acceptable, but given other inaccuracies inherent in spatial, such as the earth being approximated by a geoid, I would think that issues caused by approximating a geofence like this would be rare. If you run,
SELECT ST_Area(ST_Buffer(ST_MakePoint(0, 0), 1, num_segments));
for different values of num_seg_quarter_circle and compare to PI, you can get an idea how close you are to a true circle.
If all you need to determine if a something is within a distance of another, use ST_DWithin. You can even make it faster by using a spatial index.
If this is your use-case, this discussion of polygon v. circle is irrelevant. Buffering will always have a small amount of error, since it is complicated (e.g. number of segments and other parameters). ST_Buffer is only an approximation of a true, exact buffer. Buffering is also computationally much more expensive. See a good discussion on gis.SE, and a useful tip for newbies.
