On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd <dire...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
