Hi Colleagues!
My apologies for going quiet again: I've been reviewing the changes I suggested below on Wed 28th. Pat came back with some criticisms of those suggestions that I needed to think through and get right. I took this offline with Pat; the discussion was about type safety (as far as one can achieve this in SQL) within the BNF diagrams, so I thought I shouldn't clutter up your email unnecessarily. I carefully rethought and came up with what I think are changes minor enough for the RFC period, yet consistent with type safety such as it is in using BNF to describe SQL. I'm confident this is how it should be. It'll take me a few days to fold these changes into the parser and come up with the completed set of BNF.
So, below is my original quote. And below that what I now think is how the final BNF should read (with maybe some cosmetic changes). This covers only the region side of things plus a little more to show the consistency I'm aiming for. I've added comments to elucidate different points, and these won't be in the final version.
PLEASE, can you give me feedback if you strongly disagree! Pedro and Inaki, I need some reassurance I haven't gone too far in changing the specification. As far as I can see, Pat's points have pushed me completely in the right direction.
On Wed, 2008-05-28 at 12:05 +0100, this is what I originally suggested:
> (3) I've altered the name of <system_defined_function> to > <geometry_function> and moved <centroid> into the list. I've made minor > adjustments to the names for the sake of readability (basically I've > only used "function" where the expansion is a list of functions, which > fits in better with the definition of maths and trig functions, the one > exception being <user_defined_function>)... > > <geometry_function> ::= > <area> > | <centroid> > | <distance> > | <latitude> > | <longitude> > | <region_function> > > I've moved <centroid> here from <geometry_value_expression> to make our > approach to these functions more consistent. This also entails a small > change to an important definition... > > <geometry_value_expression> ::= <geometry_expression> | <geometry_value> > > > (4) Part of this consistency is a partial redefinition of the functions > so they now _all_ use <geometry_value_expression>. For example, > > <centroid> ::= > CENTROID <left_paren> <geometry_value_expression> <right_paren> > <area> ::= > AREA <left_paren> <geometry_value_expression> <right_paren> > <distance> ::= > DISTANCE <left_paren> <geometry_value_expression> > <comma> <geometry_value_expression> <right_paren> > <latitude> ::= > LATITUDE <left_paren> <geometry_value_expression> <right_paren> > <longitude> ::= > LONGITUDE <left_paren> <geometry_value_expression> <right_paren> > > <region_function> ::= <contains> | <intersects> > > and so on.
This is what I think should be the final version. The comments under
<value_expression> are the main driver. Functions are grouped according
to their return type...
<value_expression> ::=
<numeric_value_expression>
| <string_value_expression>
| <geometry_value_expression>
!! functions under <numeric_value_expression> return a numeric
!! functions under <string_value_expression> return a string
!! functions under <geometry_value_expression> return a geometry.
<geometry_value_expression> ::=
<value_expression_primary>
| <geometry_value_function>
!! The presence of <value_expression_primary> makes it possible to use <column_reference> as
!! a <geometry_value_expression>.
<geometry_value_function> ::=
<box> | <circle> | <point> | <polygon> | <region> | <centroid> | <user_defined_function> !! These all return a geometry. Note I've dropped <ellipse> !! <circle> | <point> | <polygon> | <region> haven't changed, so I've not included them here.
<box> ::=
BOX <left_paren> <coord_sys>
<comma> <coordinates>
<comma> <numeric_value_expression>
<comma> <numeric_value_expression>
<right_paren>
<centroid> ::=
CENTROID <left_paren> <geometry_value_expression> <right_paren>
!! Returns a <point>
!! OK, a centroid of a point or of another centroid (both of which are possible) is pretty boring!
<numeric_primary> ::=
<value_expression_primary>
| <numeric_value_function>
!! <numeric_primary> is reached via <numeric_value_expression>, so is the counterpart of
!! <geometry_value_expression>
<numeric_value_function> ::=
<trig_function>
| <math_function>
| <numeric_geometry_function>
| <user_defined_function>
!! These all return a numeric.
<numeric_geometry_function> ::=
<predicate_geometry_function>
<predicate_geometry_function> ::=
CONTAINS <left_paren> <geometry_value_expression> <comma> <geometry_value_expression> <right_paren> | INTERSECTS <left_paren> <geometry_value_expression> <comma> <geometry_value_expression> <right_paren>
<non_predicate_geometry_function> ::=
AREA <left_paren> <geometry_value_expression> <right_paren>
| COORD1 <left_paren> <coord_value> | <right_paren> | COORD2 <left_paren> <coord_value> | <right_paren> | DISTANCE <left_paren> <coord_value> <comma> <coord_value> <right_paren>!! COORD1 and COORD2 are generic substitutes for what were LATITUDE and LONGITUDE.
<coord_value> ::= <point> | <column_reference>
!! I don't think there is any need to include <centroid> here, as
!! whatever would render a <point> would be accepted, and <centroid> does just that.
<character_primary> ::=
<value_expression_primary>
| <string_value_function>
!! <character_primary> is reached via <string_value_expression>, so is the counterpart of
!! <geometry_value_expression>
<string_value_function> ::=
| <string_geometry_function>
| <user_defined_function>
!! These all return a string. I would expect more string functions in the future.
<string_geometry_function> ::= <coordsys>
<coordsys> ::= COORDSYS <left_paren> <geometry_value_expression> <right_paren>
Regards
Jeff
-- Jeff Lusted tel: +44 (0)116 252 3581 Astrogrid Project mob: +44 (0)7973 492290 Dept Physics & Astronomy email: jl99-at-star.le.ac.uk University of Leicester web: http://www.astrogrid.orgReceived on 2008-06-03Z11:26:38
<value_expression> ::=
<numeric_value_expression> | <string_value_expression> | <geometry_value_expression> !! functions under <numeric_value_expression> return a numeric !! functions under <string_value_expression> return a string !! functions under <geometry_value_expression> return a geometry.
<geometry_value_expression> ::=
<value_expression_primary> | <geometry_value_function> !! The presence of <value_expression_primary> makes it possible to use <column_reference> as !! a <geometry_value_expression>.
<geometry_value_function> ::=
<box> | <circle> | <point> | <polygon> | <region> | <centroid> | <user_defined_function> !! These all return a geometry. Note I've dropped <ellipse> !! <circle> | <point> | <polygon> | <region> haven't changed, so I've not included them here.
<box> ::=
BOX <left_paren> <coord_sys> <comma> <coordinates> <comma> <numeric_value_expression> <comma> <numeric_value_expression> <right_paren>
<centroid> ::=
CENTROID <left_paren> <geometry_value_expression> <right_paren> !! OK, a centroid of a point or of another centroid (both of which are possible) is pretty boring!
<numeric_primary> ::=
<value_expression_primary> | <numeric_value_function> !! <numeric_primary> is reached via <numeric_value_expression>, so is the counterpart of !! <geometry_value_expression>
<numeric_value_function> ::=
<trig_function> | <math_function> | <numeric_geometry_function> | <user_defined_function> !! These all return a numeric.
<numeric_geometry_function> ::=
<predicate_geometry_function> | <non_predicate_geometry_function>
<predicate_geometry_function> ::=
CONTAINS <left_paren> <geometry_value_expression> <comma> <geometry_value_expression> <right_paren> | INTERSECTS <left_paren> <geometry_value_expression> <comma> <geometry_value_expression> <right_paren>
<non_predicate_geometry_function> ::=
AREA <left_paren> <geometry_value_expression> <right_paren> | COORD1 <left_paren> <coord_value> | <right_paren> | COORD2 <left_paren> <coord_value> | <right_paren> | DISTANCE <left_paren> <coord_value> <comma> <coord_value> <right_paren> !! COORD1 and COORD2 are generic substitutes for what were LATITUDE and LONGITUDE.
<coord_value> ::= <point> | <column_reference>
!! I don't think there is any need to include <centroid> here, as !! whatever would render a <point> would be accepted, and <centroid> does just that.
<character_primary> ::=
<value_expression_primary> | <string_value_function> !! <character_primary> is reached via <string_value_expression>, so is the counterpart of !! <geometry_value_expression>
<string_value_function> ::=
| <string_geometry_function> | <user_defined_function> !! These all return a string. I would expect more string functions in the future.
<string_geometry_function> ::= <coordsys>
<coordsys> ::= COORDSYS <left_paren> <geometry_value_expression> <right_paren>