Dear Benjamin and all,
The reason I am proposing to have a region restriction as an extra clause is to simplify the implementation of region selection.
If we introduce the region criteria as a general boolean-value function, all the following syntax must be supported:
The region selection is expected to be implemented with a service-specific special algorithm to provide an efficient selection, especially for a big catalog.
The algorithm might have difficulty to implement the above criteria, so it is better to have just a simple region criteria in the *CORE* spec.
By introuducing the new REGION clause and defining that it is followed by only one region expression (may be Circle), we can enforce only a simple region criteria.
The following SQL:
SELECT *
FROM table
WHERE MAG_B > 10
REGION 'Circle 230 30 1.0'
corresponds to
SELECT *
FROM table
WHERE MAG_B > 10 AND Region('Circle 230 30 1.0')
If you want to provide region criteria as a generic one, you can use *OPTIONAL* region function.
Yuji Shirasaki
From: Benjamin Gufler <benjamin.gufler-at-in.tum.de> Subject: Region restrictions (VOQL-TEG-1/AI#2) Date: Thu, 26 Oct 2006 18:59:32 +0200
> Dear all,
>
> I'd like to start the discussion on where to place the region restrictions.
>
> I would prefer to have the region restrictions as an (optional?) part of
> the WHERE, due to the following reasons:
>
> * A region restriction is a selection criterion on for each single
> tuple, and that's what the WHERE clause is intended for
>
> * By taking REGION out of the WHERE, people would have to extend their
> SQL parsers or - even worse - rewrite them. If region restrictions
> look like function calls, an average SQL parser should work.
>
> * One can write queries with muliple selection criteria. How should
> queries containing some "normal" selections as well as region
> restrictions in a separate REGION clause behave? Should the conditions
> be connected by AND, OR, AND NOT, ...? And how about a single query
> which should retrieve data from two distinct regions?
> We would have to re-define a lot of syntactical as well as semantical
> stuff which is already available in the WHERE clause and is well-known
> to many people.
>
> Cheers,
> Benjamin
> --
> Dipl.-Inf. Benjamin Gufler Lehrstuhl Informatik III
> Tel. +49 89 289-17276 Fax +49 89 289-17263
> Boltzmannstr. 3, 85748 Garching Raum FMI 02.11.035
>
Received on 2006-10-30Z05:07:00