Dear all
Although I see pros and cons in both approaches I do believe we should give the standard the capability to support any kind of union and intersection (OR/AND) between regions and any other condition. This can be easily handled by the current syntax of the WHERE-condition clause without having to reinvent anything. We should take advantage of what is already there and, as Benjamin was saying, all the semantical and syntactical attributes falling under the WHERE condition already support this kind of structure.
Regarding any potential problem on its implementation... well, that is just that, an implementation issue related with the usage of the specification under a given protocol. At the end it would be up to the protocol to define what and what not to support. I believe the constraints on the protocol implementations should never drive the evolution of the standard. On the other hand, I still do not see why keeping the REGION outside the WHERE clause makes things easier. I think I see it the other way around.
Cheers
Inaki
Yuji SHIRASAKI wrote:
> 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:
>
> - WHERE NOT Region('Circle 230 30 1.0')
> - WHERE Region('Circle 230 30 1.0') AND Region('Circle 230 30.5 1.0')
> - WHERE Region('Circle 230 30 1.0') OR Region('Circle 230 32 1.0')
> - WHERE Region('Circle 230 30 1.0') OR MAG_B > 10
> - SELECT Region('Circle 230 30 1.0')
>
> 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
>>
>>