Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Дата | |
Msg-id | CA+TgmoaVrV-D7smLS61r2jfuRbT3V2KhCh05UvgkJOVdzWJ-3A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) (Brendan Jurd <direvus@gmail.com>) |
Ответы |
Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re:
Should array_length() Return NULL)
("David E. Wheeler" <david@kineticode.com>)
Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) (Brendan Jurd <direvus@gmail.com>) |
Список | pgsql-hackers |
On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd <direvus@gmail.com> wrote: > It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in > existing applications, so there is no way for that idiom in existing > applications to be broken by upgrading. If testing for equality with > '{}' works now, it will also work post-upgrade. I suppose, strictly speaking, that that is true, but I think there are all kinds of ways for this to go wrong. Your previous complaint was that there was no easy way to check whether an array is empty. I pointed out that there is: compare it against an empty array and see whether they are equal. Now you're saying, let's change it so we can have lots of different empty arrays, each one different from all the others. Well, that breaks the world for anybody who is using the method that works today. Sure, they've probably got to have at least some kind of application change before the wheels really start to come off, but as soon as some array that's empty but not equal to {} creeps into their application by whatever means, they've got trouble. And what's the upside? Do we really want or need an infinitude of all-distinct empty arrays? Besides, even if you're not convinced that that particular thing will break applications, there are clearly going to be cases where some array functions return different results after this change than they did beforehand. That's actually the whole point of this change. Right? And, if you change the value that a built-in function returns when given the same input, that can break user applications. > The only way for it to stop working is if somebody upgrades, and > *then* goes out of their way to create an empty array with nondefault > lower bounds, and then tries to compare that array against the empty > array with default lower bounds, to test for emptiness. Which would > be silly. > > Big picture: A very large number of users wouldn't be using arrays at > all, and of those who are, probably a vanishingly small number > (perhaps zero) care about how emptiness interacts with multiple > dimensions or nondefault lower bounds. We're talking about a corner > case inside a corner case here. I think the first half of this argument is off-point, because it's true in general, for any feature, that people who aren't using a feature won't notice if the behavior of that feature changes. But we have good evidence that even obscure, largely broken features like RULEs have user bases that are significant enough that changing the behavior of those systems will generate protest. I'd be surprised if the number of people using arrays isn't far larger than the number of people using rules for table partitioning. As to the second half, part of the point of this patch is to change things so that array_length('{}'::int4[], 1) returns non-NULL. But I myself have written code that tests for an empty array by writing array_length(blahblah, 1) IS NULL. So with your proposed change, that code would break. Sure, I would have been happier, when I wrote that code, if the return value had been 0 rather than NULL. But the return value *was* NULL, so I wrote the code that way, and it worked. I can't be the only one to have done something like that. Anyone who has would get an ugly surprise if we did what you're proposing. In a large application, it might not even be clear (until you started poking at it) what exactly had changed; and if they've got tens or hundreds of thousands of lines of code (hardly unreasonable), fixing it might be quite a chore. Imposing that pain our user base does not seem justified to me. > For most folks, this upgrade would break nothing. A few (myself > included) will want to grep their code for > array_(lower|upper|length|dims) call sites and maybe make some tweaks. I think the only people for whom nothing will break are the people who aren't using arrays in the first place. Anyone who is is likely to have dependencies on the way array_lower/upper work today. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Следующее
От: "David E. Wheeler"Дата:
Сообщение: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)