tgl wrote:
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> 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
