2013/3/26 Robert Haas <robertmh...@gmail.com>: > On Sun, Mar 24, 2013 at 10:02 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
