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]