Re: SQL99 ARRAY support proposal

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