Re: Number of dimensions of an array parameter

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Thomas Hallgren <thomas(at)tada(dot)se>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Number of dimensions of an array parameter
Date: 2006-05-09 16:31:33
Message-ID: 200605091631.k49GVXH28692@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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. +

Attachment Content-Type Size
/bjm//diff text/x-diff 769 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message imacat 2006-05-09 16:34:01 Re: Compiling PL/Perl and Pl/Python on x86_64
Previous Message PFC 2006-05-09 16:29:31 Re: [HACKERS] Big IN() clauses etc : feature proposal