Tom Lane wrote:
> 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
