Return-Path: owner-postman
Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with SMTP id RAA24027 for postgres-redist; Thu, 30 Jun 1994 17:01:10 -0700
Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199407010001.RAA24027@nobozo.CS.Berkeley.EDU>
X-Authentication-Warning: nobozo.CS.Berkeley.EDU: Host localhost.Berkeley.EDU didn't use HELO protocol
Sender: owner-postman@postgres.Berkeley.EDU
X-Return-Path: owner-postman
Received: from utopia.CS.Berkeley.EDU (utopia.CS.Berkeley.EDU [128.32.149.5]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with ESMTP id RAA24017 for <postgres@postgres.Berkeley.EDU>; Thu, 30 Jun 1994 17:01:09 -0700
Received: from localhost (sunita@localhost) by utopia.CS.Berkeley.EDU (8.6.4/8.1B) id RAA09937; Thu, 30 Jun 1994 17:00:59 -0700
Date: Thu, 30 Jun 1994 17:00:59 -0700
From: Sunita Sarawagi <sunita@postgres.Berkeley.EDU>
Message-Id: <199407010000.RAA09937@utopia.CS.Berkeley.EDU>
To: Aaron.Roydhouse@Comp.VUW.AC.NZ, postgres@postgres.Berkeley.EDU
Subject: Re:  Strange array_in behaviour
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Thu, 30 Jun 94 17:01:10 -0700
Resent-XMts: smtp



> The array_in proceeds frequently rejects seemingly valid
> multidimensional array string constants, consider the attached
> example. Can anyone explain this behaviour? It would be quite painful
> if I have to make all sub-arrays of equal size in string constants.

You have to provide one of two things to the array_in procedure
to enable it to work correctly. Either you provide the full *complete
string* (I will describe a *complete string* next) or  provide the
exact dimension of the array after the attribute name. In the Postgres
array implementation we do *not* keep any indexing information about
the array global to the whole relation. So, it is not necessary to
have all array tuples of the relation to be of the same size and
dimension. But, each individual tuple has to follow the rule I just
mentioned for the code to behave sanely.

A *complete string* in the context of a multi-dimensional array is one
that lists all elements of the array so that it is possible to get
all information about the dimensionality of the array from the string.
In your example "{{1,2,3,4,5},{1,2,3,4,5}}" is a complete string and
"{{1,2,3,4,5},{1,2,3}}" is not (Although array_in wrongly accepts the
string it does not store the full string as you can see by doing a retrieve).  
Incomplete strings like "{{1,2,3,4,5},{1,2}}" can be readily accepted
by specifying the dimension as:

* append foo (list[2][5] = "{{1,2,3,4,5},{1,2}}")\g

The unspecified elements are initialized to 0.

A session is given below:

* create foo (list = oid[][])\g

Query sent to backend is "create foo (list = oid[][])"
CREATE
Go 
* append foo (list = "{{1,2,3,4,5},{1,2,3,4,5}}")\g

Query sent to backend is "append foo (list = "{{1,2,3,4,5},{1,2,3,4,5}}")"
APPEND 377370
Go 
* append foo (list[3][2] = "{11,12}")\g

Query sent to backend is "append foo (list[3][2] = "{11,12}")"
APPEND 377371
Go 
* retrieve (foo.all)
\g

Query sent to backend is "retrieve (foo.all) "
---------------
| list        |
---------------
| {{1,2,3,4,5},{1,2,3,4,5}}|
---------------
| {{11,12},{0,0},{0,0}}|
---------------

-----------------------------------------------------------

> On a related note, what are the storage requirements of
> multidimensional arrays? Just the number of elements appended, or the
> product of the maximum size in each dimension?

This should be clear from the above explanation.

------------------------------------------------------------------


Sunita Sarawagi

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================
