From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Parser translations and schemas |
Date: | 2002-04-24 18:28:06 |
Message-ID: | Pine.LNX.4.30.0204241426360.682-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> You write You get
>
> char(N) pg_catalog.bpchar
> pg_catalog.char pg_catalog.char (not bpchar)
> real pg_catalog.float4
> myschema.real myschema.real (not float4)
> trim(BOTH foo) pg_catalog.btrim(foo)
> pg_catalog.trim(BOTH foo) an error (since the special production
> allowing BOTH won't be used)
Exactly my thoughts.
> A corner case that maybe requires more discussion is what about type and
> function names that are reserved per spec, but which we do not need any
> special transformation for? For example, the spec thinks that
> OCTET_LENGTH() is a keyword, but our implementation treats it as an
> ordinary function name. I feel that the grammar should not prefix
> "pg_catalog." to any name that it hasn't transformed or treated
> specially in any way, even if that name is reserved per spec.
I agree.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Pimlott | 2002-04-24 18:29:28 | non-standard escapes in string literals |
Previous Message | Peter Eisentraut | 2002-04-24 18:24:48 | Re: Inefficient handling of LO-restore + Patch |