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: