Re: Exposing keywords to clients - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: Exposing keywords to clients
Date
Msg-id 20080502232421.GB4774@alvh.no-ip.org
Whole thread Raw
In response to Exposing keywords to clients  ("Dave Page" <dpage@pgadmin.org>)
Responses Re: Exposing keywords to clients
Re: Exposing keywords to clients
List pgsql-patches
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.


> 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.


--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Next
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Sigh ...