On Thu, 2011-02-10 at 13:07 -0500, Robert Haas wrote:
> According to our documentation[1], RANGE is reserved in SQL:2008 and
> SQL:2003, which makes it more imaginable to reserve it than it would
> be otherwise.
Oh, interesting.
> I believe that in a previous email you mentioned that
> you were hoping to implement RANGE JOIN, and I will just note that the
> restrictions of the grammar require that any keyword that immediately
> follows the previous expression and precedes JOIN must be fully
> reserved. I'm not sure if you meant that a range join would literally
> use the syntax RANGE JOIN, but if so then you're going to have to
> argue for fully reserving RANGE anyway, in which case there'd be no
> special reason not to allow RANGE [1,10) to mean just that. On the
> other hand, if a RANGE JOIN just means a regular join on some funky
> operator, and there's no other reason to reserve range, I wouldn't do
> it just to get a nicer syntax here.
It's mostly just a regular join on a funky operator. We may want that
operator to allow a new plan (range merge join); but I think we can
determine that it's a range join from the use of the operator. I'll have
to look into that more.
> Have you done investigation of what RANGE is used to mean in the SQL
> spec? Is what you're implementing (a) spec, (b) similar idea, but not
> the spec, or (c) something completely different? I'm guessing (c) but
> I have no idea what the spec is using it for.
(c) was my intention. I did take a brief look at the spec a while back,
but I'll take a more detailed look. I think it only has to do with
window specifications.
This might solve the constructor problem nicely if we could do things
like: RANGE[10,20)
But I have a feeling that will either cause a bizarre problem with the
grammar, or someone will think it's not very SQL-like.
Regards,Jeff Davis