| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Paul Ramsey <pramsey(at)refractions(dot)net>, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, dblasby(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PostGIS Integration |
| Date: | 2004-02-04 07:23:08 |
| Message-ID: | 40209DDC.2080306@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Those two cases are not hard, because in those scenarios the parser
> knows it is expecting a type specification. The real problem is this
> syntax for typed literals:
> typename 'string'
> which occurs in ordinary expressions. So when you see "name(" you
> aren't real sure if you're seeing the start of a function call or the
> start of a typed-literal construct. And it's very hard to postpone that
> decision until you see what comes after the right paren.
Just disallow that particular case for custom types :P
Will this work: 'string'::typename
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-02-04 07:48:00 | Re: PostGIS Integration |
| Previous Message | Tom Lane | 2004-02-04 07:07:06 | Re: PostGIS Integration |