4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays - Mailing list pgsql-hackers

From J. Greg Davidson
Subject 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays
Date
Msg-id 1304979903.14349.86.camel@shevek.puuhonua.org
Whole thread Raw
Responses Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays  (Merlin Moncure <mmoncure@gmail.com>)
Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
E.1.2.2. Casting            * Tighten casting checks for domains based on arrays (Tom Lane)               When a domain
isbased on an array type,..., such a domain type       is no longer allowed to match an anyarray parameter of a
polymorphicfunction, 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.

Thanks,

_Greg



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Inconsistent treatment of serials in pg_dump
Next
From: "J. Greg Davidson"
Date:
Subject: Server Programming Interface underspecified in 4.1beta1