Number of dimensions of an array parameter

Thomas Hallgren <thomas@tada.se> writes:

Only allow arrays with one dimension unless the parameter is of a domain
type (domains are apparently stored with the actual number of
dimensions).

No, they don't enforce dimensionality any more than ordinary array
columns do. typndims and attndims are both effectively just booleans:
is it an array or not?

IMO, there is something seriously wrong here. Clearly the number of
dimensions is a property of the type.

[ shrug... ] That's debatable. You could just as well argue that the
exact array size should be enforced by the type system.

regards, tom lane

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

Stefan Kaltenbrunner wrote:

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. "

A documented flaw is much better than an undocumented one but it's still
a flaw, and a pretty bad one at that. It's like having a compiler that
doesn't complain when you define a C-function that takes an int** and
then pass an int*.

Would it be hard to enforce a real check? The implementation could use
GUC settings like 'enforce_array_dimensions' and 'enforce_array_lengths'
that could be set to false for the legacy implementations that rely on
the current behavior. I know Tom added the ability to have NULL values
in the arrays. Perhaps now is the time to improve the type semantics as
well?

Regards,
Thomas Hallgren

thhal=# CREATE DOMAIN twodims as int[][];
CREATE DOMAIN

While still not perfect, you can use a CHECK constraint on the domain to
enforce dimension.

It's not perfect because domain constraints are not enforced in all
locations in versions earlier than 8.2. Adding extra explicit casts can
often work around that though.

ru=# create domain twodims as int[][] check(array_dims(value) =
'[1:2][1:2]');

ru=# select
array_dims('{{{1,2},{3,4}},{{5,3},{9,9}}}'::twodims);
ERROR: value for domain twodims violates check constraint
"twodims_check"

ru=# select array_dims('{{1,2},{3,4}}'::twodims);
array_dims
------------
[1:2][1:2]
(1 row)

If you want to be fancy, use something like this:

check(array_dims(value) ~ '^[1:\\d+][1:\\d+]$');

--

On Mon, May 08, 2006 at 07:31:14PM +0200, Thomas Hallgren wrote:

Would it be hard to enforce a real check? The implementation could use
GUC settings like 'enforce_array_dimensions' and 'enforce_array_lengths'
that could be set to false for the legacy implementations that rely on
the current behavior. I know Tom added the ability to have NULL values
in the arrays. Perhaps now is the time to improve the type semantics as
well?

The big probem is where do you store the number of declared dimensions?
It's not stored anywhere, so there's nowhere to check against either.
If we can fix that first we might get to the checking part.

test=# create function foo(int[][]) returns int4 as 'select 1' language sql;
CREATE FUNCTION
test=# \df foo
List of functions
Result data type | Schema | Name | Argument data types
------------------+--------+------+---------------------
integer | public | foo | integer[]
(1 row)

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Thomas Hallgren <thomas@tada.se> writes:

Would it be hard to enforce a real check? The implementation could use
GUC settings like 'enforce_array_dimensions' and 'enforce_array_lengths'
that could be set to false for the legacy implementations that rely on
the current behavior.

The fact that it doesn't exactly match Java semantics does not make it
"legacy behavior". I don't agree that it's a bug; I think it's a
feature, precisely because many functions can work on arrays of
different dimensions. Why should we change to make PL/Java happier,
when it will move us further away from the semantics of, say, PL/R?

I think reasonable choices for PL/Java would be to reject
multidimensional array arguments, or to silently ignore the
dimensionality and treat the data as 1-D in storage order
(as I think plperl for instance already does).

regards, tom lane

Tom Lane wrote:

Thomas Hallgren <thomas@tada.se> writes:

Would it be hard to enforce a real check? The implementation could use
GUC settings like 'enforce_array_dimensions' and 'enforce_array_lengths'
that could be set to false for the legacy implementations that rely on
the current behavior.

The fact that it doesn't exactly match Java semantics does not make it
"legacy behavior". I don't agree that it's a bug; I think it's a
feature, precisely because many functions can work on arrays of
different dimensions. Why should we change to make PL/Java happier,
when it will move us further away from the semantics of, say, PL/R?

Would it really? The way I see it, the choice of language is irrelevant.
Either you support dimensions or you don't. The way PostgreSQL does it,
you get the impression that it is supported while in fact it's not. I
can't see how anyone would consider that a feature. If you want the
ability to use an arbitrary number of dimensions, then you should have a
syntax that supports that particular use-case. An int[][] cannot be
anything but a two dimensional int array. Not in my book anyway. That
opinion has nothing to do with Java.

I think reasonable choices for PL/Java would be to reject
multidimensional array arguments, or to silently ignore the
dimensionality and treat the data as 1-D in storage order
(as I think plperl for instance already does).

I agree. That's the way I'll do it.

Regards,
Thomas Hallgren

Martijn van Oosterhout wrote:

On Mon, May 08, 2006 at 07:31:14PM +0200, Thomas Hallgren wrote:

Would it be hard to enforce a real check? The implementation could use
GUC settings like 'enforce_array_dimensions' and 'enforce_array_lengths'
that could be set to false for the legacy implementations that rely on
the current behavior. I know Tom added the ability to have NULL values
in the arrays. Perhaps now is the time to improve the type semantics as
well?

The big probem is where do you store the number of declared dimensions?
It's not stored anywhere, so there's nowhere to check against either.
If we can fix that first we might get to the checking part.

test=# create function foo(int[][]) returns int4 as 'select 1' language sql;
CREATE FUNCTION
test=# \df foo
List of functions
Result data type | Schema | Name | Argument data types
------------------+--------+------+---------------------
integer | public | foo | integer[]
(1 row)

Let each type have it's own entry in pg_type. I.e. let the int[] and
int[][] be two distinct types (like int and int[] already are). In
addition, perhaps introduce a new syntax that denotes 'arbitrary number
of dimensions' and let that too be a distinct type.

Regards,
Thomas Hallgren

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. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Documentation updated to mention "dimmensions" are not enforced.

This patch seems entirely pointless, since the point is already made
(with correct spelling even) in the very next line.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Documentation updated to mention "dimmensions" are not enforced.

This patch seems entirely pointless, since the point is already made
(with correct spelling even) in the very next line.

Thanks, reverted.

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

+ If your life is a hard drive, Christ can be your backup. +