Re: [HACKERS] PostGIS Integration

2004-02-04 Thread strk
tgl wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> 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 parti

Re: [HACKERS] PostGIS Integration

2004-02-04 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> 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 typ

Re: [HACKERS] PostGIS Integration

2004-02-04 Thread Christopher Kings-Lynne
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

Re: [HACKERS] PostGIS Integration

2004-02-04 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> I can't see any way to handle parameterized types without extending the >> grammar individually for each one --- otherwise it's too hard to tell >> them apart from function calls. > Disallow it in table definitions, but allow it in domain defi

Re: [HACKERS] PostGIS Integration

2004-02-04 Thread Christopher Kings-Lynne
I can't see any way to handle parameterized types without extending the grammar individually for each one --- otherwise it's too hard to tell them apart from function calls. That makes it a bit hard to do 'em as plug-ins :-(. The grammar hacks are certainly ugly though, and if someone could think

Re: [HACKERS] PostGIS Integration

2004-02-03 Thread Tom Lane
Paul Ramsey <[EMAIL PROTECTED]> writes: > I think we had this discussion before though, and the "parameterized" > types, like varchar(256), were not available for extended types, like > our geometries. I can't see any way to handle parameterized types without extending the grammar individually f