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