Given: CREATE DOMAIN int_array AS int[];
The operator [] works fine in 4.1beta1: SELECT (ARRAY[1,2,3]::int_array)[1]; proving that int_array is an array type with element type int. It is inconsistent that other array functions and operators don't work. On Mon, 2011-05-09 at 23:32 -0400, Tom Lane wrote: > So we basically had three alternatives to make it better: > #1 downcast to the array type, which would possibly silently > break applications that were relying on the function result > being considered of the domain type I do not think of this as "Downcasting int_array to int[]" but as allowing an ANYARRAY to match int_array which is an array type. Since no cast is logically required, the return type is the same as the first argument type, as expected and as PostgreSQL has done for some time. > #2 re-apply domain checks on the function result, which would be > a performance hit and possibly again result in unobvious > breakage If the function result is a new value then nothing is being re-applied. If it is an existing value of the domain type which was passed in or extracted from a data structure, then the domain checks have already been applied. This is a red herring. > #3 explicitly break it by throwing a parse error until you > downcast (and then upcast the function result if you want) > I realize that #3 is a bit unpleasant, but are either of the other two > better? At least #3 shows you where you need to check for problems. Wrapping most (but not all) of your array operations in downcasts and upcasts is horrible. > There is another issue that wasn't really mentioned in the previous > thread, which is that if we are matching a domain-over-array to a > function's ANYARRAY argument, what exactly should be allowed to match to > ANYELEMENT --- or if the function returns ANYELEMENT, what should the > imputed result type be? Since PostgreSQL allows indexing of the domain type, we already know the answer. I don't even get why there is confusion abou the element type of an array. > AFAICS it's impossible to give an answer to > that without effectively deciding that function argument matching > smashes the domain to its base type (the array type). It's not very > clear what's the point of a domain type if every operation on it is > going to neglect its domain-ness. Yes, what is the point of neglecting the domain-ness of a domain type by being forced to downcast it to an unchecked type before (some) array operations? If a value is being constructed of a domain-type which has constraints, check them. When I don't want the security of a domain type I can cast it to its representation type before I passed it, but it seems bizarre to be required to do such a thing! I did read the previous threads some time ago. They seemed mostly to be concerned with discussing the internal implementation of these matters and the typmod feature (which I still don't understand). The internal algorithms and deta structures which PostgreSQL uses to internally represent SQL types and operations are a weak justification for PostgreSQL's behavior - they can be changed if they are wrong. I am still hoping to get rid of my domains which are arrays when PostgreSQL supports arrays of elements which are of domain types. Could we at least defer this change until that is done? _Greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
