Nikhils <[EMAIL PROTECTED]> writes:
>>> Attached is an updated patch, giving the following output.
Applied with minor revisions.
> Here are some comments from me:
> a) Changed "localised" to "localized" to be consistent with the references
> elsewhere in the same file.
What I didn't like about
Hi,
> > Attached is an updated patch, giving the following output.
> >
> > Oh, one other thing: dropping externs into random modules unrelated to
> > their source module is completely awful programming style, because there
> > is nothing preventing incompatible declarations. Put those externs in
On Sat, May 3, 2008 at 9:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > Attached is an updated patch, giving the following output.
>
> Oh, one other thing: dropping externs into random modules unrelated to
> their source module is completely awful programmi
"Dave Page" <[EMAIL PROTECTED]> writes:
> Attached is an updated patch, giving the following output.
Oh, one other thing: dropping externs into random modules unrelated to
their source module is completely awful programming style, because there
is nothing preventing incompatible declarations. Put
"Dave Page" <[EMAIL PROTECTED]> writes:
> Attached is an updated patch, giving the following output. The catdesc
> column can be translated.
Documentation has got a couple of problems:
> + contains the keyword, the catcode column contains a
> + category code of 'U' for unknown, 'C' for co
On Sat, May 3, 2008 at 6:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Is there anything useful you would do with this information? Or would you
> > just quote all listed words anyway?
Currently, yes, we just quote all listed words.
> I think the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Dave Page wrote:
>>> 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 objection
Dave Page wrote:
> > 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?
Is there anything useful you would do with this
On Sat, May 3, 2008 at 12:24 AM, Alvaro Herrera
<[EMAIL PROTECTED]> 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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> 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 v
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 highlightin
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 mu
12 matches
Mail list logo
