You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had to dig into the ADQL grammar in another matter, too: CENTROID.
For one, pgSphere so far doesn't support computing centroids (except
for circles and points, which is lame), so I suspect nobody supports
this properly. I, at least, don't, and now try to give a sensible
error message.
But while digging into this I noticed back then I've quitely
sanitised the grammar, and I think we should fix this "upstream" now.
So, something like CENTROID(47839) or CENTROID(COUNT(*)) is
grammatically ok, and I suspect that was not what people had in mind.
I suspect what they wanted was to allow a column reference. So, I
think what we want is
The other alternatives in <value_expression_primary> don't really
make sense for any place <geometry_value_expression> turns up in.
On the other hand, what I've been running all these past years was
essentially
geometryExpression = box | point | circle | polygon | region
geometryValue = columnReference.copy()
centroid = (CaselessKeyword("CENTROID")("fName")
+ '(' + Args(geometryValueExpression) + ')')
geometryValueExpression = geometryExpression | geometryValue | centroid
I can't promise I really thought the inclusion of centroid in
geometryValueExpression, but I'd support including it in
<geometry_value_expression>, too. It's probably not deadly
important, but it'd allow stuff like
From an email discussion with Markus
I had to dig into the ADQL grammar in another matter, too: CENTROID.
For one, pgSphere so far doesn't support computing centroids (except
for circles and points, which is lame), so I suspect nobody supports
this properly. I, at least, don't, and now try to give a sensible
error message.
But while digging into this I noticed back then I've quitely
sanitised the grammar, and I think we should fix this "upstream" now.
Currently, we have
So, something like CENTROID(47839) or CENTROID(COUNT(*)) is
grammatically ok, and I suspect that was not what people had in mind.
I suspect what they wanted was to allow a column reference. So, I
think what we want is
The other alternatives in <value_expression_primary> don't really
make sense for any place <geometry_value_expression> turns up in.
On the other hand, what I've been running all these past years was
essentially
I can't promise I really thought the inclusion of centroid in
geometryValueExpression, but I'd support including it in
<geometry_value_expression>, too. It's probably not deadly
important, but it'd allow stuff like
or similar.
The text was updated successfully, but these errors were encountered: