Re: Number of dimensions of an array parameter - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Number of dimensions of an array parameter
Date
Msg-id 200605091631.k49GVXH28692@candle.pha.pa.us
Whole thread Raw
In response to Re: Number of dimensions of an array parameter  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: Number of dimensions of an array parameter
List pgsql-hackers
Documentation updated to mention "dimmensions" are not enforced.

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

Stefan Kaltenbrunner wrote:
> Thomas Hallgren wrote:
> > I can create a function that takes a two dimension int array:
> >
> >  CREATE FUNCTION twodims(int[][]) RETURNS void AS ...
> >
> > but there's nothing stopping me from calling this function with an
> > arbitrary number of dimensions on the array.
> >
> > I'd like to map a parameter like the one above to a corresponding
> > representation in Java (it would be int[][] there too). As it turns out,
> > I can't do that. PostgreSQL will not store any information that can tell
> > me how many dimensions that where used in the declaration, i.e. it's
> > impossible to write a language VALIDATOR that, based on the information
> > in pg_proc, builds a signature where the number of dimensions is reflected.
> >
> > This leaves me with two choices:
> >
> > Only allow arrays with one dimension unless the parameter is of a domain
> > type (domains are apparently stored with the actual number of
> > dimensions). Any call that uses an array parameter with more then one
> > dimension will yield an exception.
> >   --OR--
> > Always map to Object[] instead of mapping to the correct type, . This
> > will work since an array in Java is also an Object and all primitive
> > types can be represented as objects (i.e. int can be a
> > java.lang.Integer). The strong typing and the ability to use primitives
> > are lost however.
> >
> > I'm leaning towards #1 and hoping that PostgreSQL will enhance the
> > parameter type declarations to include the dimensions in future releases.
> >
> > ... After some more testing ...
> >
> > Unfortunately, I run into problems even when I use domains. Consider the
> > following:
> >
> > thhal=# CREATE DOMAIN twodims as int[][];
> > CREATE DOMAIN
> > thhal=# SELECT typndims FROM pg_type WHERE typname = 'twodims';
> > typndims
> > ----------
> >        2
> > (1 row)
> >
> > thhal=# SELECT
> > array_dims('{{{1,2,3},{3,4,3}},{{5,3,2},{9,9,9}}}'::twodims);
> >   array_dims   -----------------
> > [1:2][1:2][1:3]
> > (1 row)
> >
> > IMO, there is something seriously wrong here. Clearly the number of
> > dimensions is a property of the type. Any array with a different number
> > of dimensions should yield an error or at least be coerced into the
> > right number of dimensions.
>
> while it would be nice to improve that - it is actually documented quite
> clearly.
>
> http://www.postgresql.org/docs/current/static/arrays.html has:
>
> "However, the current implementation does not enforce the array size
> limits ? the behavior is the same as for arrays of unspecified length.
>
> Actually, the current implementation does not enforce the declared
> number of dimensions either. Arrays of a particular element type are all
> considered to be of the same type, regardless of size or number of
> dimensions. So, declaring number of dimensions or sizes in CREATE TABLE
> is simply documentation, it does not affect run-time behavior. "
>
>
>
> Stefan
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/array.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/array.sgml,v
retrieving revision 1.49
diff -c -c -r1.49 array.sgml
*** doc/src/sgml/array.sgml    23 Apr 2006 03:39:47 -0000    1.49
--- doc/src/sgml/array.sgml    9 May 2006 16:30:24 -0000
***************
*** 49,55 ****
  </programlisting>

    However, the current implementation does not enforce the array size
!   limits — the behavior is the same as for arrays of unspecified
    length.
   </para>

--- 49,56 ----
  </programlisting>

    However, the current implementation does not enforce the array size
!   or dimmension limits — the behavior is the same as for
! arrays of unspecified
    length.
   </para>


pgsql-hackers by date:

Previous
From: PFC
Date:
Subject: Re: [PERFORM] Big IN() clauses etc : feature proposal
Next
From: imacat
Date:
Subject: Re: Compiling PL/Perl and Pl/Python on x86_64