From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Missing array support |
Date: | 2003-06-29 03:03:28 |
Message-ID: | 3EFE5700.7020402@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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 a scalar
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-06-29 03:29:55 | Re: join_references: variable not in subplan target lists |
Previous Message | Francisco Figueiredo Jr. | 2003-06-29 01:56:55 | Re: Getting blocked when receinving response from a Parse |
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Björklund | 2003-06-29 05:40:50 | Re: CVS tip compile failure (was Re: Missing array support) |
Previous Message | Joe Conway | 2003-06-29 01:24:09 | Re: CVS tip compile failure (was Re: Missing array support) |