Tom Lane wrote:
>
> Thomas Lockhart <[EMAIL PROTECTED]> 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
