Re: [PATCHES] array concat, et al patch
Joe Conway <[EMAIL PROTECTED]> writes: > Here's a patch for the documentation updates. Please apply. Applied with one small change --- I thought the last example failed to make the point that the elements of an ARRAY[] construct could be dissimilar. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] array concat, et al patch
Tom Lane wrote:
You're on the hook for docs fixes...
Here's a patch for the documentation updates. Please apply.
Thanks,
Joe
Index: doc/src/sgml/array.sgml
===
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/array.sgml,v
retrieving revision 1.29
diff -c -r1.29 array.sgml
*** doc/src/sgml/array.sgml 9 Aug 2003 22:50:21 - 1.29
--- doc/src/sgml/array.sgml 19 Aug 2003 05:31:16 -
***
*** 162,168
expression syntax is discussed in more detail in .
-
--- 162,167
***
*** 326,334
||.
SELECT ARRAY[1,2] || ARRAY[3,4];
!?column?
! ---
! {{1,2},{3,4}}
(1 row)
SELECT ARRAY[5,6] || ARRAY[[1,2],[3,4]];
--- 325,333
||.
SELECT ARRAY[1,2] || ARRAY[3,4];
! ?column?
! ---
! {1,2,3,4}
(1 row)
SELECT ARRAY[5,6] || ARRAY[[1,2],[3,4]];
***
*** 337,363
{{5,6},{1,2},{3,4}}
(1 row)
The concatenation operator allows a single element to be pushed on to the
beginning or end of a one-dimensional array. It also accepts two
N-dimensional arrays, or an N-dimensional
! and an N+1-dimensional array. In the former case, the two
! N-dimension arrays become outer elements of an
! N+1-dimensional array. In the latter, the
! N-dimensional array is added as either the first or last
! outer element of the N+1-dimensional array.
!
! When extending an array by concatenation, the subscripts of its existing
! elements are preserved. For example, when pushing
! onto the beginning of an array with one-based subscripts, the resulting
! array has zero-based subscripts:
SELECT array_dims(1 || ARRAY[2,3]);
array_dims
[0:2]
(1 row)
--- 336,403
{{5,6},{1,2},{3,4}}
(1 row)
+
+
The concatenation operator allows a single element to be pushed on to the
beginning or end of a one-dimensional array. It also accepts two
N-dimensional arrays, or an N-dimensional
! and an N+1-dimensional array.
!
+
+ When a single element is pushed on to the beginning of a one-dimensional
+ array, the result is an array with a lower bound subscript equal to
+ the righthand operand's lower bound subscript, minus one. When a single
+ element is pushed on to the end of a one-dimensional array, the result is
+ an array retaining the lower bound of the lefthand operand. For example:
SELECT array_dims(1 || ARRAY[2,3]);
array_dims
[0:2]
(1 row)
+
+ SELECT array_dims(ARRAY[1,2] || 3);
+ array_dims
+
+ [1:3]
+ (1 row)
+
+
+
+
+ When two arrays with an equal number of dimensions are concatenated, the
+ result retains the lower bound subscript of the lefthand operand's outer
+ dimension. The result is an array comprising every element of the lefthand
+ operand followed by every element of the righthand operand. For example:
+
+ SELECT array_dims(ARRAY[1,2] || ARRAY[3,4,5]);
+ array_dims
+
+ [1:5]
+ (1 row)
+
+ SELECT array_dims(ARRAY[[1,2],[3,4]] || ARRAY[[5,6],[7,8],[9,0]]);
+ array_dims
+
+ [1:5][1:2]
+ (1 row)
+
+
+
+
+ When an N-dimensional array is pushed on to the beginning
+ or end of an N+1-dimensional array, the result is
+ analogous to the element-array case above. Each N-dimensional
+ sub-array is essentially an element of the N+1-dimensional
+ array's outer dimension. For example:
+
+ SELECT array_dims(ARRAY[1,2] || ARRAY[[3,4],[5,6]]);
+ array_dims
+
+ [0:2][1:2]
+ (1 row)
***
*** 386,394
(1 row)
SELECT array_cat(ARRAY[1,2], ARRAY[3,4]);
!array_cat
! ---
! {{1,2},{3,4}}
(1 row)
SELECT array_cat(ARRAY[[1,2],[3,4]], ARRAY[5,6]);
--- 426,434
(1 row)
SELECT array_cat(ARRAY[1,2], ARRAY[3,4]);
! array_cat
! ---
! {1,2,3,4}
(1 row)
SELECT array_cat(ARRAY[[1,2],[3,4]], ARRAY[5,6]);
Index: doc/src/sgml/func.sgml
===
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.167
diff -c -r1.167 func.sgml
*** doc/src/sgml/func.sgml 17 Aug 2003 04:52:41 - 1.167
--- doc/src/sgml/func.sgml 19 Aug 2003 04:32:27 -
***
*** 7093,7099
||
array-to-array concatenation
ARRAY[1,2,3] || ARRAY[4,5,6]
! {{1,2,3},{4,5,6}}
--- 7093,7099
||
array-to-array concatenation
ARRAY[1,2,3] || ARRAY[4,5,6]
! {1,2,3,4,5,6}
***
*** 7121,7126
--- 7121,7131
+See for more details with regard to operator
+behavior.
+
+
+
shows the functions
available for use with array types. See
for more discussion and examples for the use of these functions.
***
**
Re: [PATCHES] array concat, et al patch
Tom Lane wrote: Applied with only marginal changes. (I thought the element-type checks removed from parse_expr.c had better be applied at runtime; and I noticed that array_cat scribbled on its inputs in some cases.) Thanks! You're on the hook for docs fixes... I'm on it. Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] array concat, et al patch (was: [GENERAL] join of array)
Joe Conway <[EMAIL PROTECTED]> writes: > The attached patch fixes code and regression tests for the following > 1) Array concatenation of equidimensional arrays: > 2) Array literals or vars in ARRAY expressions: > 3) Lower bound of outer array adjusted downward when an "element" (which > could itself be an array) is concatenated onto the front of an array: Applied with only marginal changes. (I thought the element-type checks removed from parse_expr.c had better be applied at runtime; and I noticed that array_cat scribbled on its inputs in some cases.) > docs to follow once > I'm sure what actually ends up being committed. You're on the hook for docs fixes... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] array concat, et al patch (was: [GENERAL] join of array)
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Joe Conway wrote:
> Tom Lane wrote:
> > Could you look at how big a change it'd be, anyway? Offhand I think it
> > may just mean that the subscript-checking done in parse_expr.c needs to
> > be done at runtime instead. Remember parse_expr should only be
> > concerned about determining datatype, and for its purposes all arrays of
> > a given element type are the same --- subscript checking should happen
> > at runtime. (It seems likely that having an ndims field in ArrayExpr
> > is inappropriate.)
>
> The attached patch fixes code and regression tests for the following
> (docs to follow once applied):
>
>
> 1) Array concatenation of equidimensional arrays:
>
> regression=# select ARRAY[1,2] || ARRAY[3,4];
> ?column?
> ---
> {1,2,3,4}
> (1 row)
>
> regression=# select ARRAY[[1],[2],[3]] || ARRAY[[4],[5]];
> ?column?
> ---
> {{1},{2},{3},{4},{5}}
> (1 row)
>
> regression=# select ARRAY[[1,2],[2,3],[3,4]] || ARRAY[[4,5],[5,6]];
> ?column?
> -
> {{1,2},{2,3},{3,4},{4,5},{5,6}}
> (1 row)
>
>
>
> 2) Array literals or vars in ARRAY expressions:
>
> regression=# create table arr(f1 int[], f2 int[]);
> CREATE TABLE
> regression=# insert into arr values (ARRAY[[1,2],[3,4]],ARRAY[[5,6],[7,8]]);
> INSERT 2635544 1
> regression=# select ARRAY[f1,f2] from arr;
> array
> ---
> {{{1,2},{3,4}},{{5,6},{7,8}}}
> (1 row)
>
> regression=# select ARRAY['{{1,2},{3,4}}'::int[],'{{5,6},{7,8}}'::int[]];
> array
> ---
> {{{1,2},{3,4}},{{5,6},{7,8}}}
> (1 row)
>
>
>
> 3) Lower bound of outer array adjusted downward when an "element" (which
> could itself be an array) is concatenated onto the front of an array:
>
> regression=# create table arr(f1 int[]);
> CREATE TABLE
> regression=# insert into arr values ('{}');
> INSERT 2635538 1
> regression=# update arr set f1[-2] = 1;
> UPDATE 1
> regression=# select array_lower(f1,1) from arr;
> array_lower
> -
>-2
> (1 row)
>
> regression=# select array_lower(f1 || 2, 1) from arr;
> array_lower
> -
>-2
> (1 row)
>
> regression=# select array_lower(0 || f1, 1) from arr;
> array_lower
> -
>-3
> (1 row)
>
> regression=# update arr set f1 = ARRAY[[1,2],[3,4]];
> UPDATE 1
> regression=# select array_lower(f1,1) from arr;
> array_lower
> -
> 1
> (1 row)
>
> regression=# select array_lower(f1 || ARRAY[5,6], 1) from arr;
> array_lower
> -
> 1
> (1 row)
>
> regression=# select array_lower(ARRAY[-1,0] || f1, 1) from arr;
> array_lower
> -
> 0
> (1 row)
>
>
> Compiles without warnings and passes all regression tests. If there are
> no objections, please apply. As I mentioned above, docs to follow once
> I'm sure what actually ends up being committed.
>
> Joe
> Index: src/backend/executor/execQual.c
> ===
> RCS file: /opt/src/cvs/pgsql-server/src/backend/executor/execQual.c,v
> retrieving revision 1.141
> diff -c -r1.141 execQual.c
> *** src/backend/executor/execQual.c 8 Aug 2003 21:41:39 - 1.141
> --- src/backend/executor/execQual.c 15 Aug 2003 21:52:30 -
> ***
> *** 1620,1635
> ArrayType *result;
> List *element;
> Oid element_type = arrayExpr->element_typeid;
> ! int ndims = arrayExpr->ndims;
> int dims[MAXDIM];
> int lbs[MAXDIM];
>
> ! if (ndims == 1)
> {
> int nelems;
> Datum *dvalues;
> int i = 0;
>
> nelems = length(astate->elements);
>
> /* Shouldn't happen here, but if length is 0, return NULL */
> --- 1620,1637
> ArrayType *result;
> List *element;
> Oid element_type = arrayExpr->element_typeid;
> ! int ndims = 0;
> int dims[MAXDIM];
> int lbs[MAXDIM];
>
> ! if (!arrayExpr->multidims)
