Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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;
(1 row)

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

(1 row)

regression=# select f[1][1][1] from z;
(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.


> 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?


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-06-29 03:29:55
Subject: Re: join_references: variable not in subplan target lists
Previous:From: Francisco Figueiredo Jr.Date: 2003-06-29 01:56:55
Subject: Re: Getting blocked when receinving response from a Parse

pgsql-patches by date

Next:From: Dennis BjörklundDate: 2003-06-29 05:40:50
Subject: Re: CVS tip compile failure (was Re: Missing array support)
Previous:From: Joe ConwayDate: 2003-06-29 01:24:09
Subject: Re: CVS tip compile failure (was Re: Missing array support)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group