Open mbtaylor opened 6 months ago
Hi @mbtaylor .
This is a known behavior....but, of course, it is undesired. It has already been fixed in the next coming release of ADQL (branch adql2.1
): https://github.com/gmantele/vollt/commit/7ada398b9bb13f94e950051e3856b95632a66985#diff-7f5b3b1d90449d14a965fa8e0a86538a79005d50b0f84d11027cd177b689d537
The problem actually came from the parser which was too strict. It will be fixed for ADQL-2.1 queries.
Hi @gmantele - the above output is using the jar file adql-2.0-beta.jar, which IIRC corresponds to the tag adqlLib-2.0-beta
which is a point on branch adql2.1
later in the history than 7ada398. So I think this remains unfixed.
Ok. Then, I'll try to look at this in more details sometime next week.
Hi @gmantele. I noticed some ADQL queries using UDFs that are declared to return
POINT
values are not being parsed as I'd expect; if they are used as the argument of e.g.COORD1
, the parsing reports a syntax error, though standard ADQL geometry functions can be used in such positions. This is the case even though the relevantFunctionDef.isGeometry()
call returns true. I present a short program that demonstrates this:which produces the following output:
I am using
adqlLib-2.0-beta
.Is this known/expected behaviour? Thanks.