| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| 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:48:00 |
| Message-ID: | 7784.1075880880@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> 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'
> Just disallow that particular case for custom types :P
Well, maybe we could --- comments? Tom Lockhart went to some lengths to
support that, but now that he's gafiated we could perhaps rethink it.
AFAICS the SQL spec only requires this syntax for certain built-in types.
Tom wanted to generalize that to all datatypes that Postgres supports,
and that seems like a reasonable goal ... but if it prevents getting to
other reasonable goals then we ought to think twice.
> Will this work: 'string'::typename
Yes, since the :: cues the parser to expect a typename next.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Koichi Suzuki | 2004-02-04 09:25:12 | Re: PITR Dead horse? |
| Previous Message | Christopher Kings-Lynne | 2004-02-04 07:23:08 | Re: PostGIS Integration |