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 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 ; 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 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. ==============================================================================