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