By analogy to the "type 'literal'" syntax? I'd prefer not to go that route, because that syntax for literals is a horrid kluge --- to keep bison from spitting up, we've had to put a bunch of nasty restrictions on the type names that can appear in such constructs. All those restrictions would have to apply here, too.
It's possible that we could use the other cast syntaxes: ARRAY[1,2,3]::integer[] CAST(ARRAY[1,2,3] AS integer[]) It would take some hackery to propagate the destination type down into the ARRAY[] before the latter's type resolution is done, but at least it'd be a quite localized hack.
OK -- I'll try to make that work. I presume that in the non-specified case "ARRAY[1,2,3]" I should use something similar to UNION's resolution rules?
<array value constructor by enumeration> ::= ARRAY <left bracket or trigraph> <array element list> <right bracket or trigraph> <array value constructor by query> ::= ARRAY <left paren> <query expression> [ <order by clause> ] <right paren>
This I could live with --- note the difference in punctuation. There would be a clear syntactic and semantic difference between ARRAY(SELECT ...) and ARRAY[(SELECT ...)].
Sorry -- I guess I mis-read that. So "ARRAY(SELECT ...)" it is.
> [...lots of good ideas regarding generalizing array operations...]
I played with generalizing array functions a bit for plr and ran into some problems (which I can't specifically recall at the moment), but clearly that's the way to go. I'll start playing with your suggestions in C code, and report back for more feedback as it solidifies.
Thanks!
Joe
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
