2013/3/26 Robert Haas <robertmhaas@gmail.com>:
> On Sun, Mar 24, 2013 at 10:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 03/20/2013 04:45 PM, Brendan Jurd wrote:
>>> Incompatibility:
>>> This patch introduces an incompatible change in the behaviour of the
>>> aforementioned array functions -- instead of returning NULL for empty
>>> arrays they return meaningful values. Applications relying on the old
>>> behaviour to test for emptiness may be disrupted. One can
>>
>> As a heavy user of arrays, I support this patch as being worth the
>> breakage of backwards compatibility. However, that means it certainly
>> will need to wait for 9.4 to provide adequate warning.
>
> I expect to lose this argument, but I think this is a terrible idea.
> Users really hate it when they try to upgrade and find that they, uh,
> can't, because of some application-level incompatibility like this.
> They hate it twice as much when the change is essentially cosmetic.
> There's no functional problems with arrays as they exist today that
> this change would solve.
>
> The way to make a change like this without breaking things for users
> is to introduce a new type with different behavior and gradually
> deprecate the old one. Now, maybe it doesn't seem worth doing that
> for a change this small. But if so, I think that's evidence that this
> isn't worth changing in the first place, not that it's worth changing
> without regard for backwards-compatibility.
>
> Personally, I think if we're going to start whacking around the
> behavior here and risk inconveniencing our users, we ought to think a
> little larger. The fundamental thing that's dictating the current
> behavior is that we have arrays of between 1 and 6 dimensions all
> rolled up under a single data type. But in many cases, if not nearly
> all cases, what people want is, specifically, a one-dimensional array.
> If we were going to actually bite the bullet and create separate data
> types for each possible number of array dimensions... and maybe fix
> some other problems at the same time... then the effort involved in
> ensuring backward-compatibility might seem like time better spent.
>
I understand, but I don't agree. W have to fix impractical design of
arrays early. A ARRAY is 1st class - so there is not possible to use
varchar2 trick.
if we don't would to use GUC, what do you think about compatible
extension? We can overload a system functions behave. This can solve a
problem with updates and migrations.
Regards
Pavel
> --
> 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
