Re: FWD: tinterval vs interval on pgsql-novice

Tom Lane wrote:
> 
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> >> 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?
> 
> > 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?
> That all sounds fine, but it doesn't seem to fix the problem I'm looking
> at, which is that the OVERLAPS production is broken in current sources:

Yes it does. When you execute
 select (timestamp 'today', interval '1 day')  OVERLAPS (timestamp 'yesterday', timestamp 'tomorrow');

This is matched up with an entry in pg_proc which declares an SQL
language implementation as
 'select overlaps($1, ($1+$2), $3, $4)'

which is what fails.

It may be better to declare this as
 'select ($1, ($1+$2)) overlaps ($3, $4)'

but that is not what is there now. I've just tested the latter form and
it seems to work, so I'll include that in my next patchball.
                     - Thomas