Re: Missing array support

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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)