From: | Thomas Hallgren <thomas(at)tada(dot)se> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Number of dimensions of an array parameter |
Date: | 2006-05-08 17:31:14 |
Message-ID: | 445F8062.1060206@tada.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-05-08 17:34:25 | Pragma linking? |
Previous Message | Jeffrey Tenny | 2006-05-08 17:29:28 | performance question (something to do w/ parameterized stmts?, wrong index types?) |