Skip site navigation (1) Skip section navigation (2)

Re: Parser translations and schemas

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 (view raw, whole thread or download thread mbox)
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

In response to

pgsql-hackers by date

Next:From: Andrew PimlottDate: 2002-04-24 18:29:28
Subject: non-standard escapes in string literals
Previous:From: Peter EisentrautDate: 2002-04-24 18:24:48
Subject: Re: Inefficient handling of LO-restore + Patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group