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:
        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.



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to