On Wed, Feb 9, 2011 at 2:09 AM, Jeff Davis <pg...@j-davis.com> wrote: > That's how arrays do it: there's a special Expr node that represents an > array expression. Maybe the same thing could be used for range types, > but I fear that there may be some grammar conflicts. I doubt we'd want > to fully reserve the keyword "range".
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. 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] http://www.postgresql.org/docs/current/static/sql-keywords-appendix.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers