Обсуждение: Latest parser changes

> Add PATH as a type-specific token, since PATH is in SQL99
> to support schema resource search and resolution.

You do realize this broke the geometry regress test?
        regards, tom lane

> > Add PATH as a type-specific token, since PATH is in SQL99
> > to support schema resource search and resolution.
> You do realize this broke the geometry regress test?

Um, er, I guess not. But I *did* make one round of fixes to get the
regression tests to pass (by allowing PATH as a type name in gram.y),
and my recollection is that the PATH naming problem had actually
affected several regression tests. That is no longer the case on my
machine (i.e. only one test fails).

So I'm guessing again (my development laptop is powered off right now)
that the regression test is only partially damaged, perhaps with a
column name problem?? I'll try to look at it this weekend.
                 - Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> So I'm guessing again (my development laptop is powered off right now)
> that the regression test is only partially damaged, perhaps with a
> column name problem?? I'll try to look at it this weekend.

The problem is this query now fails:  SELECT '' AS four, path(f1) FROM POLYGON_TBL;
! ERROR:  parser: parse error at or near "("

Evidently, although "path" is still accepted as a type name, it's
not allowable as a function name, which puts a crimp in type coercion.

AFAICT from a quick scan of SQL99, PATH is only intended to be used
in specialized contexts like SET PATH.  It is *not* a data type nor
needed in type-related constructs.

I think this could be fixed by removing the generic->PATH_P production
and allowing PATH to be a ColId instead of just a ColLabel.  Of course,
that just makes one wonder why bother to make it a keyword yet, when
we don't yet have any productions that need it...
        regards, tom lane