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
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
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
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
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
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
