> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> > select ('today', interval '1 day') OVERLAPS ('yesterday', interval '18
> > hours');
> > (the second one fails). Now that I look, this breakage was introduced in
> > March when "we" expunged operators allowed as identifiers (Tom Lane and
> > I have blood on our hands on this one ;) See gram.y around line 5409.
> I see it does fail, but I'm at a complete loss to understand why,
> especially given that the first case still works. The grammar looks
> perfectly fine AFAICT. Can you explain what's wrong here?
Yes. There is one underlying routine implementing the OVERLAPS operator.
As you might expect, it is called overlaps() in the catalog, has an
entry point of overlaps_timestamp(), and takes four arguments of type
timestamp. The other variants which accept an interval type for the
second and/or fourth arguments are defined in pg_proc.h as SQL
procedures which simply add, say, the first and second arguments to end
up with four timestamp arguments.
The SQL routine explicitly calls overlaps() as a function, which is
currently disallowed.
Here is what I'm planning on doing (already tested, but not committed).
I'm adding some productions to the func_name rule in gram.y to handle
the various "stringy operators" such as LIKE and OVERLAPS. These tokens
will also be allowed in the ColLabel rule (as several are already).
This fixes the immediate problem, and makes LIKE handling more
consistant with other special functions. Comments?
- Thomas