[gmantele]

In this PullRequest, the goal is to finally recommend a syntax for:

1. the serialization of values typed as REGION
2. the string parameter for the function creating regions: REGION(VARCHAR)

The recommended syntax is the one defined for the DALI xtype shape.

Conversion from and into STC-s serializations is possible using a User Defined Function that the UDF Catalogue would provide:

• stcs_to_region(VARCHAR) -> REGION
• region_to_stcs(REGION) -> VARCHAR

If this idea is approved, these functions must be added to the UDF Catalogue before ADQL-2.2 becomes REC (or in the same time).

The function REGION(VARCHAR) may still support other serializations (like STC-s) but the DALI syntax MUST be supported in all implementations. At least for this new minor version of ADQL, I think we should be that permissive in order to allow a good support of ObsCore. But, in the future (when ObsCore will be updated accordingly), should we forbid anything else than a DALI syntax?

Fixes #90

[msdemlei]

Minor things:

• s/v1.2 and upper/v1.2 and later/
• Please use the ivoatex admonition environment for your admonition box (https://ivoa.net/documents/Notes/IVOATexDoc/20250402/NOTE-ivoatexDoc-1.5-20250402.html#tth_sEc3.1)

As to the actual content: turning REGION into shape-s may be the last bad thing we can do since the thing is there and people feel the need for polymorphous geometries. However, if it's xtype=shape, then "is introduced as the type of the result of unions of other geometries" is not true, and it's probably not good enough for ESO's use case either. shape is just polygon, circle, range, or point (and I hope MOC at some point). Were you thinking about multishape?

Either way, I think we have to define what

  SELECT TOP 1 REGION('circle 10 10 1') AS geo FROM TAP_SCHEMA.tables

returns. Am I forced to have this be an xtype=shape column containing exactly this string? Could I return an xtype=circle column, too? The latter would make this a lot more realistic for implementation (though still a minor pain).

If we make REGION accept multishape-s (which is what I think people have been asking for), things get a lot worse. Consider:

SELECT TOP 1 REGION('polygon 10.0 10.0 10.2 10.0 10.2 10.2 10.0 10.2 circle 10.0 10.0 0.2 circle 14.0 14.0 0.2') as geo FROM TAP_SCHEMA.tables

At least in current pgsphere, I can't possibly pull this through the database in a halfway robust way. So, what do I return?

Me, I think we have to be explicit that there is no expectation that you get anything like the input geometry specification out again. For my implementation, the only realistic thing I see is to return a MOC. If that's ok to do, I can see the whole plan fly; otherwise, I'd like to see an implementation.

[pdowler]

The REGION function has a defined return type and practically we can chose shape or multishape, the latter being closer to what non-normative STC-S allowed... probably multishape.

In that case, the example query above has a constant in the select list and the column is clearly

datatype="char" arraysize="*" xtype="multishape"

This particular example doesn't require that the value (other than the string) be round-tripped through the database as a geometry, but it isn't hard to make an example that does have to be treated like a geometry.

REGION was always hard to deal with as an input geometry and that doesn't really change by defining it in terms of multishape (well, it is slightly simpler because only union, but not a lot). In general I feel like multishape is viable as a detailed output but it crosses the line of "more complicated than valuable" as an input geometry.