Re: Missing array support

Peter Eisentraut wrote:
> It doesn't say anything specifically about multidimensional arrays, but
> the grammar clearly allows declaring arrays of arrays.
> 
>          <data type> ::=
>                 <predefined type>
>               | <row type>
>               | <user-defined type>
>               | <reference type>
>               | <collection type>
> 
>          <collection type> ::=
>                 <data type> <array specification>
> 
>          <array specification> ::=
>               <collection type constructor>
>                   <left bracket or trigraph> <unsigned integer> <right bracket or trigraph>
> 
>          <collection type constructor> ::=
>                 ARRAY

Yeah, I noticed that after I replied. So  <data type> <array specification>
means something like this is valid  integer ARRAY[3] ARRAY[4] ARRAY[5]
?

Is this the same then as our syntax?  integer [3][4][5]

> This also has some consequences for the cardinality function.  In order to
> get the cardinality of the second dimension, you'd need to call
> cardinality(a[1]).  (I suppose it allows different cardinalities at
> various positions, so the array does not need to be an n-dimensional
> rectangle.)

Hmmm. So this implies that if arr is a 2D array, we need to treat: arr as a 2D array arr[n] as a 1D array arr[n][m] as
ascalar
 

If that's true, we have a good bit of work left to do to be compliant; e.g.:

regression=# select f from z;                                         f
-----------------------------------------------------------------------------------
{{{1,1},{1,1},{1,1}},{{1,1},{1,1},{1,1}},{{1,1},{1,1},{1,1}},{{1,1},{1,1},{1,1}}}
(1 row)

regression=# select f[1][1] from z; f
---

(1 row)

regression=# select f[1][1][1] from z; f
--- 1
(1 row)

Based on the above, "select f[1][1] from z;" ought to result in "{1,1}"?


>>select * from unnest(array['a','b']) as t(f1, f2) WITH ORDINALITY;
>>  f1 | f2
>>----+----
>>  1  | a
>>  2  | b
> 
> 
> The WITH ORDINALITY goes before the AS clause.

OK

> The reason it is defined in terms of the LATERAL clause is that that
> allows you to refer to column aliases defined in FROM items to its left.
> This is the way variable arguments of function calls as table sources can
> be resolved.  (At least this is my interpretation.  I found some examples
> on the web a few months ago about this.)

Thanks for explaining that. I've never seen a LATERAL clause, and I was 
wondering just what this part meant. So this applies to the discussion 
we had a while back about set returning functions in the targetlist?

Joe