On Mon, May 9, 2011 at 6:25 PM, J. Greg Davidson <greg@ngender.net> wrote:
>
> E.1.2.2. Casting
>
> * Tighten casting checks for domains based on arrays (Tom Lane)
>
> When a domain is based on an array type,..., such a domain type
> is no longer allowed to match an anyarray parameter of a
> polymorphic function, except by explicitly downcasting it to the
> base array type.
>
> This will require me to add hundreds of casts to my code. I do not get
> how this will "Tighten casting checks". It will certainly not tighten
> my code! Could you explain how it is good to not be able to do array
> operations with a type which is an array?
>
> BTW: All of my DOMAINs which are array types exist because of
> PostgreSQL's inability to infer array types for DOMAINs, so I
> have lots of code like this:
>
> CREATE DOMAIN foo_ids AS integer;
> CREATE DOMAIN foo_id_arrays AS integer[];
>
> I would love to be able to simply use foo_ids[] instead of
> having to have the second DOMAIN foo_id_arrays.
>
> If there is some value which I'm missing in the above "Tighten"ing,
> perhaps it could be put in *after* PostgreSQL were given the ability
> to understand foo_ids[] as an array of foo_ids.
I didn't read the thread that led up to this change (see:
http://postgresql.1045698.n5.nabble.com/Domains-versus-arrays-versus-typmods-td3227701.html)
but if I had, I would have argued that the problem cases listed, the
worst being the failed constraint check, do not justify the
compatibility break :(. In the pre-unnest() world, you might have
gotten away with it, but it's been out for two released versions (and
some ad hoc approaches for longer than that) and perhaps we were too
quick on the trigger. Considering we've already got a report during
beta1, this does not exactly inspire confidence.
We've got other cases of known bugs where a good solution is unclear
or breaks unknown amounts of user code. The giant clusterfark
surrounding is null and composites comes to mind.
merlin