Re: Exposing keywords to clients

On Sat, May 3, 2008 at 12:24 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Dave Page wrote:
> > Hi,
> >
> > The attached patch implements a new function, pg_get_keywords(), which
> > returns a set of records describing the keywords recognised by the
> > server. This allows clients such as pgAdmin to get quoting rules
> > correct, and helps with other tasks such as syntax highlighting where
> > we need to support multiple server versions.
>
> FWIW pg_dump has fmtId() which does something related.
>
> I think it's a bit bogus to be using the list as compiled client-side,
> precisely due to the theoretical chance that it could change from one
> server version to the next, but it's probably not very likely that we
> ever remove a keyword from the server grammar. And highlighting a
> keyword that's not really a keyword is unlikely to be a problem in
> practice -- in fact it makes it obvious that the user is likely to be in
> trouble later when they upgrade.

Yeah, we currently lift a copy of keywords.c into the pgAdmin source
and use that in our own qtIdent() function, but it's clearly only
correct for the version of Postgres we pull it from, whilst pgAdmin
supports back to 7.3 in current releases. It's also a pain because we
try to support some of the derivative servers like those offered by
Greenplum and EnterpriseDB which may have additional keywords (though
that obviously is not a problem for this community).

> > postgres=# select * from pg_get_keywords();
> > word | category
> > -------------------+-----------------------
> > all | Reserved
> > binary | Type or function name
> > xmlserialize | Column name
> > zone | Unreserved
> > (372 rows)
> >
> > I wasn't sure about the best way to describe the categories -
> > obviously they need to be non-translatable (for client software to
> > interpret), but human readable is also nice. I'm happy to hear
> > alternate suggestions.
>
> Perhaps use a separate string for machine parse (say R, T, C, U), and
> let the string be translatable.

I considered that, but wasn't sure if folks would like the redundancy.
It's trivial to do of course - any objections?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com