Re: [HACKERS] PostGIS Integration
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 of a way, I'm all ears... Disallow it in table definitions, but allow it in domain definitions... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostGIS Integration
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 definitions... 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. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostGIS Integration
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 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PostGIS Integration
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 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. If it's not for SQL conformance I don't think we really need to generalize that. As far as there are other means to gain the same result... 'string'::type(parameter) can be the general postgres version. while varchar(2) 'string' can be the standard SQL version (not general). --strk; Will this work: 'string'::typename Yes, since the :: cues the parser to expect a typename next. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] PostGIS Integration
Actually, in my wet dream, we stored everything in system tables. Dimensionality and SRID became parameters of the geometry, the selectivity stats lived in the system stats table (as Mark's patch should hopefully do) and the geometry_columns view just pulled everything together into one user-convenient location. CREATE TABLE foo ( mygeom POLYGON(4326) ); CREATE TABLE bar ( mygeom MULTILINESTRING(20711, 2 ) ); I think we had this discussion before though, and the parameterized types, like varchar(256), were not available for extended types, like our geometries. P. On Tuesday, February 3, 2004, at 12:06 PM, Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Oh, now I remember. The deal was not views, it was triggers. Oh, okay. You're right, we don't do triggers on system tables. But couldn't you combine a view on the system tables with storage of additional data outside? regards, tom lane Paul Ramsey Refractions Research Email: [EMAIL PROTECTED] Phone: (250) 885-0632 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostGIS Integration
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 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 of a way, I'm all ears... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
