Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays
От | Merlin Moncure |
---|---|
Тема | Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays |
Дата | |
Msg-id | BANLkTimE=EVOmQWUeDZnZ+1hPP0c=cY=Cw@mail.gmail.com обсуждение исходный текст |
Ответ на | 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays ("J. Greg Davidson" <greg@ngender.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: